On 27 Feb 2018, at 17:07, Torvald Riegel <trie...@redhat.com> wrote: > > On Tue, 2018-02-27 at 16:40 +0000, Simon Wright wrote: >> On 27 Feb 2018, at 12:56, Ruslan Nikolaev via gcc <gcc@gcc.gnu.org> wrote: >>> >>> And all this mess to accommodate almost non-existent case when someone >>> wants to use atomic_load on read-only memory for wide types, in which no >>> good solution exists anyway >> >> Sorry to butt in, but - if it's ROM why would you need atomic load anyway? >> (of course, if it's just a constant view of the object, reason is obvious) > > Consider a producer-consumer relationship between two processes where > the producer doesn't want to wait for the consumer. For example, the > producer could be an application that's being traced, and the consumer > is a trace aggregation tool. The producer can provide a read-only > mapping to the consumer, and put a nonblocking ring buffer or something > similar in there. That allows the consumer to read, but it still needs > atomic access because the consumer is modifying the ring buffer > concurrently.
OK, got that, thanks (this is what I meant by "just a constant view of the object", btw). Misled by "read-only memory" since in the embedded world ROM (usually actually in Flash) is effectively read-only to all.
