On Tuesday, 27 August 2013 at 17:35:13 UTC, qznc wrote:
On Monday, 26 August 2013 at 19:35:28 UTC, luminousone wrote:
I have been working on a project and needed a good concurrent
queue
What does "good" mean? Concurrent queues have so many design
parameters (single reader? single writer? blocking? bounded?
etc) and there is no queue, which performs optimal for every
case.
Generally, multiple writers and a single reader, but multiple
writers and multiple readers may also occur.
I can recommand this paper (paywalled though):
http://dl.acm.org/citation.cfm?id=248106
Nevertheless, I believe you rather wanted some comments on your
specific code. I wonder why you implemented spinlocks yourself?
If you write a blocking algorithm, you should probably use the
phobos locks.
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.
