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