Re: Concurrency via isolated process/thread

[Ihor Radchenko <yantar92@posteo.net>]

Po Lu <luangruo@yahoo.com> writes:

> 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.)

This is a dangerous assumption.
What if Emacs decides to support such architecture in future?

Simultaneous write and read generally has undefined outcome, unless we
use READ_ONCE and WRITE_ONCE. There are known architectures where
simultaneous read may result in mixing bits from the old and new values.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>