Re: Concurrency via isolated process/thread

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

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

No such architecture is likely to run Emacs in the future, because it
will fail to support every single piece of multiprocessing software
written up to now.

And if Emacs does need to support such an architecture in the future
(which is a very long shot), we can revisit our choices then.  Until
that time, I see no need to slow down reads and writes to conses or
vectors with interlocking on the basis of purely theoretical
considerations.

> Simultaneous write and read generally has undefined outcome

Only the order in which the reads and writes appear to take place is
undefined.  Provided that only valid Lisp_Objects are written, no
invalid Lisp_Object will ever be read.

>, unless we use READ_ONCE and WRITE_ONCE.

Emacs is not the Linux kernel and is not subject to its considerations.
Besides, READ_ONCE and WRITE_ONCE involve _NO_ interlocking!

> There are known architectures where simultaneous read may result in
> mixing bits from the old and new values.

Which architectures would that be?  Unless you're describing unaligned
reads and writes, or for data types larger or smaller (on the 21064)
than a machine word.