First off. Many thanks for all the links. I will read them avidly.

With respect to out-of-date material. I am concious that I wouldn't even know without lookingit up, what is the current version of anything *nix. So, dates and versions go right over my head. In part, that's the reason for seeking expert advice.

but I looked at the mutex code for more recent libc releases (2.12), and pthread_mutex_lock runs completely in user-space unless contention occurs.

That's cool, and a great advance. But it still means acquiring a lock that I don't need or want, for every iteration at both ends. It may be that with modern mutexes and low contention, that is insignificant, but it still dictates a certain algorithmic logic that is effectively the reverse of what I actually need.

It means acquiring the mutex every time, and signalling every time in case someone else was waiting on it. And doing that at both ends every time.

The theory of my design is that you block or signal if you hit one end of the buffer or the other. The rest of the time, no blocking or signalling is required. Ultimately, the notion is to have the code monitor itself for the frequency of under/over-runs, and increase the size of the buffer (semi-automatically within bounds) if they are too frequent.

If the buffer was unlimited, then everything can be added, and everything removed without ever encountering a block except at start-up and close-down. That's impractical for real world systems, but so long as the producer produces just slightly faster than the consumers consume, that nirvana is theoretically achievable within practical memory bounds. Of course, there will always be some other threads that will intervene and upset the apple cart, but the hope is to minimise them, not eliminate them completely.

I'm also looking at starting with a brief spin loop falling over to a (context switch inducing) micro-sleep to save cpu. In theory this can reduce elective context switches by an order of magnitude or more.

The other part of the reason for asking here, is to find actual implementations for reference. Whilst using MS Event objects works quite well, I'm still seeking to do better. This isn't an urgent (for me) problem to be solved, but part of an ongoing research into better mechanisms.

If there is a widely ported, reliable library available, then it makes sense for me to try and use/crib from that for my Windows implementation. Both because it is likely quicker for me to benefit from others labours; but also because if this ever makes it to release, it would potentially make porting it to (some) *nixes easier should anyone care to take on that task.