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.
