improve concurrent queue

[luminousone]

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.