Wait-free thread communication

Ola Fosheim Grøstad via Digitalmars-d digitalmars-d at puremagic.com
Sat Jan 9 14:44:53 PST 2016


On Saturday, 9 January 2016 at 17:42:41 UTC, David Nadlinger 
wrote:
> Not only that. It's a problem on x86 as well because advanced 
> optimizers like those in GDC or LDC will happily assume that 
> the members are not written to by another thread (because there 
> would be a race otherwise) and cache the loads or even 
> eliminate some stores. Any guarantees the processor would offer 
> are irrelevant if the compiler has already reordered your 
> operations. It should be quite easy to see such effects. Just 
> compile a simple test case on GDC or LDC with optimizations on.

Yes, well, he had a sleep() in there that might prevent the 
compiler from moving instructions etc, but even if so... it is a 
bad thing to rely on.

Explicit atomics document what is going on (even when not 
technically needed), and should always be used where you want 
atomic operations, I think.

> That would certainly be a starting point, although a 
> high-performance single-producer single-consumer queue is 
> trivial to implement once you understand atomics.

Yes. But my experience from writing custom multi-single queues is 
that it can end up harder than it looks to get it working and 
efficient. Don't be surprised if it takes 5-10x more time than 
anticipated to get it 100% right...

So why not start with something that is correct? You still have 
to spend quite a bit of time to verify that the code is 
identical... but that is much easier than to "formally" prove 
that your own implementation is correct.

(Intuition is often wrong in this area...)




More information about the Digitalmars-d mailing list