Re: Concurrency via isolated process/thread

[Po Lu]

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?

> Sure. I just meant that we need to avoid data races.

Again, there are NO data races on systems Emacs supports.

> Using READ/WRITE_ONCE or mutexes.

So nothing needs to be done.

> READ/WRITE_ONCE should be actually avoided

Because on the hypothetical systems that Emacs will need to support in
the future _and_ do not coherently propagate word sized writes between
CPUs, they must be implemented with interlocking, either in hardware or
in software.  Mutexes, of course, will then need to be implemented on
top of that.

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