On Tue, 2018-02-27 at 17:29 +0000, Ruslan Nikolaev wrote: > > > > 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. > Sorry for getting into someone's else conversation... And what good solution > gcc offers right now? It forces producer and consumer to use lock-based (BTW: > global lock!)
It's not one global lock, but a lock from an array of locks (global per process, though). > approach for *both* producer and consumer if we are talking about 128-bit > types. But we're not talking about that special case of 128b types here. The majority of synchronization doesn't need more than machine word size. > Therefore, sometimes producers *will* wait (by, effectively, blocking). > Basically, it becomes useless. No, such a program would have a bug anyway. It wouldn't even synchronize properly. Please make yourself familiar with what the standard means by "address-free". This use case needs address-free, so that's what the program has to ensure (and it can test that portably). Only lock-free gives you address-free. > In this case, I would rather use a lock-based approach which at least does > not use a global lock. The lock would need to be shared between processes in the example I gave. You have to build your own lock for that currently, because C/C++ don't give you any process-shared locks.
