Wait-free thread communication

thedeemon via Digitalmars-d digitalmars-d at puremagic.com
Sat Jan 9 00:28:33 PST 2016


On Friday, 8 January 2016 at 16:58:59 UTC, Jin wrote:
> Idea: no mutex, no CAS, only one direction queues without any 
> locks.
>
> My prototype (https://github.com/nin-jin/go.d) is up to 10x 
> faster than std.concurrency.send/receive

Sorry, that's not looking any good.
You call it wait-free when in fact it's just the opposite: if a 
queue buffer is full on push  it just waits in Thread.sleep which 
is
1) not wait-free at all
2) very heavy (call to kernel, context switch)

And when buffer is not full/empty it works as a simple 
single-threaded queue, which means it's fine for using with 
fibers inside one thread but will not work correctly in 
multithreaded setting.

Your benchmarks show time difference in your favor just because 
you compare very different things: your queue is benchmarked in 
single thread with fibers while std.concurrency is measured with 
multiple threads communicating with each other. Doing many 
switches between threads is much slower than switching between 
fibers in one thread, hence the time difference. It's not that 
your queue is any good, it's just you measure it wrong.


More information about the Digitalmars-d mailing list