improve concurrent queue

[Guillaume Piolat via Digitalmars-d-learn]

On Tuesday, 27 August 2013 at 19:50:03 UTC, luminousone wrote:
>
> I was under the impression that the atomic spinlock has a lower 
> latency for any waiters, then a mutex when its unlocked?
>
> I am using this for a temporary or depending on performance, a 
> perminate replacement for std.concurrency send/receive until 
> such time as bugs in std.variant are fixed.
>
> I have a thread with an opengl context, and I am using the 
> queue to send messages to this thread containing interface 
> Drawable objects, that have any needed preprocessing on them 
> done such that only opengl calls have to be made to the video 
> card to render it.

A mutex usually have a very fast uncontended path. It only blocks 
and is slow when already taken.

You can think of it like a spinlock + a blocking safety net.
In the uncontended case, the mutex with fast path will hardly be 
any slower than a spinlock.


Use a spinlock instead if:
- you are dead sure you won't spin for "too long"
- you don't need being reentrant
- you don't want this performance hysteresis (fast while 
uncontended, slow when things begin to creep in thread queues)