[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Concurrency via isolated process/thread

From: Ihor Radchenko
Subject: Re: Concurrency via isolated process/thread
Date: Tue, 25 Jul 2023 07:59:35 +0000

Po Lu <luangruo@yahoo.com> writes:

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

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

Sure. I just meant that we need to avoid data races. Using
READ/WRITE_ONCE or mutexes. READ/WRITE_ONCE should be actually avoided,
AFAIK. They will degrade performance significantly (one-two orders of
magnitude) for each individual operation (see Figure 5.1 in the
McKenney's book)

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>

reply via email to

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