[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Concurrency via isolated process/thread

From: Po Lu
Subject: Re: Concurrency via isolated process/thread
Date: Fri, 07 Jul 2023 08:41:21 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

Ihor Radchenko <yantar92@posteo.net> writes:

> Same with variables - even if some global variable needs to be locked,
> it is unlikely that it will need to be accessed by another thread.

I doubt symbol value cells will need to be individually interlocked.
Emacs Lisp code will need to insert the appropriate instructions to
prevent the CPU from undertaking optimizations on load and store
operations on those cells when necessary.  Imagine a situation where a
secondary thread writes the result of an expensive computation to X, and
then sets a flag to indicate its completion:

(defvar X nil)
(defvar Y nil)

thread 1:

       (setq X (some-expensive-computation))
       ;; __machine_w_barrier ()
       (setq Y t)
       ;; On machines that don't do this automatically, flush the cache
       ;; eventually.

A second thread then waits for Y to be set, indicating completion:

       (when Y
         ;; __machine_r_barrier ()
         (do-something-with X))

If the barrier instructions are not inserted, Y could be set to t before
X is set to the result of the computation, and the main thread could
also load X prior to loading (and inspecting) Y.  But there would be no
chance of a previously read value of either X or Y appearing after a new
value becoming visible or a partially written value of X or Y being
read, forgoing the need for any locking being performed on the
individual symbols themselves.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]