Wait-free thread communication

[Jin via Digitalmars-d]

On Saturday, 9 January 2016 at 08:28:33 UTC, thedeemon wrote:
> 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.

No, jin.go creates new native thread on every call. And this is 
problem :-) We can not create thousand of threads without errors.

std.concurrency uses mutex to synchromize access to message 
queue. Cost of syncronization is proportional to count of threads.

On Saturday, 9 January 2016 at 08:28:33 UTC, thedeemon wrote:
> 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.

Taking data from empty queue and pushing data to full queue is 
logicaly impossible for queues. We have 3 strategies for this 
cases:
1. Throwing runtime exception, like std.concurrency.send on full 
message box by default.
2. Blocking thread, like std.concurrency.receive on empty message 
box.
2. Skipping action.

jin-go uses blocking strategy by default and you can check 
queue.empty and queue.full if you want to implement other 
strategy.