Wait-free thread communication

[Jin via Digitalmars-d]

On Monday, 28 March 2016 at 17:16:14 UTC, Dmitry Olshansky wrote:
>>> If nothing changed implementation-wise this is just data-racy 
>>> queues :)
>>
>> Why?
>
> All I see is a ring buffer with hand-wavy atomicFence on one of 
> mutating operations. popFront is not protected at all.

popFront does not need protection. It is atommic for provider.

> Also force yielding a thread is not a sane synchronization 
> technique.

Here the fibers are used.

> Over all - I suggest to not label this as "wait free" code as 
> it's waaay far from what it takes to get that.

Each operation (clear,front,popFront,full,put) has a fixed number 
of steps if you checks for clear before access to front and check 
for full before put. If you not check this - you will be blockek 
of cource. What do you expect? Exception? Ignore?