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)
