Re: Concurrency via isolated process/thread

[Ihor Radchenko <yantar92@posteo.net>]

Po Lu <luangruo@yahoo.com> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> McKenney (2023) Is Parallel Programming Hard, And, If So, What Can You
>> Do About It? p. 483
>>
>>     "For an example, consider
>>     embedded systems with 32-bit pointers and 16-bit busses.
>>     On such a system, a data race involving a store to and a
>>     load from a given pointer might well result in the load
>>     returning the low-order 16 bits of the old value of the
>>     pointer concatenated with the high-order 16 bits of the
>>     new value of the pointer."
>
> Emacs supports such systems?  And they are SMPs as well?

My point is that it will be very difficult to support such systems in
future if we decide that we want to rely upon safety of concurrent read
and write.

>> AFAIK. They will degrade
>> performance significantly (one-two orders of magnitude) for each
>> individual operation (see Figure 5.1 in the McKenney's book)
>
> Figure 5.1 in that book illustrates the scalability of x86 interlocked
> instructions by comparing an increment mechanism using plain loads and
> stores to an atomic increment mechanism.  It is not relevant to the
> subject at hand.

I understood that figure and the associated section differently.
Do you have some kind of reference showing the performance of
READ_ONCE/WRITE_ONCE?

If we need less interlocks, it will certainly make things easier, but I
do not want to run into hard-to-debug bugs caused by data races.

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