[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: Tue, 25 Jul 2023 08:20:45 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

Ihor Radchenko <yantar92@posteo.net> writes:

> This problem is not limited to buffers - any low-level function that
> modifies C object struct must enforce the condition when other threads
> cannot modify the same object. For example SETCAR will have to mark the
> modified object non-writable first, set its car, and release the lock.

No, because reading the car of a Lisp_Cons does not depend on any other
field within the Lisp_Cons.

No interlocking is required to read from or write to machine word-sized
fields, as changes to such fields are always propagated coherently to
other CPUs.  At worst, you will need to flush the write cache on any CPU
that has written to one such field.  (Even these machines are rare -- I
don't think Emacs currently supports any.)

Interlocking is only required when correctly interpreting the value of
one field requires the state of other field(s) to be the same as when
the first field was set.  For example, PT and PT_BYTE must always be
interlocked: a thread must not see one value of PT and then read an
earlier or later PT_BYTE corresponding to a different value.

reply via email to

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