On Wed, Jun 10, 2009 at 11:34 AM, Jonathan Franklin < franklin.jonathan@gmail.com> wrote:
On Wed, Jun 10, 2009 at 9:19 AM, Zachary Turner<divisortheory@gmail.com> wrote:
This isn't the best multi-threaded design in the world, but it's basically a naive implementation of a producer consumer that uses a deque as the production queue, a boost::mutex as the lock, and a boost::condition as a signal to wake up when there's stuff in the queue (queue comment about boost::circular_buffer, which this code really should be using instead).
Are you using the "swap trick" on the queue, or synchronizing each push/pop?
I find that keeping a local queue in the thread which is processing the shared queue, and just swapping it with the shared queue when the local copy is empty eliminates most of the synchronization on the queue processing side. The threads pushing work onto the shared queue still have to synchronize, but you can't really get around that... Even w/ shared circular buffers AFAIK.
I can try that, but it's not going to be simple due to the fact that the producer / consumer code is one that is part of a 3rd party library that we can't modify the source to, so basically it means I'd have to write my own. which isn't that bad, but it still sucks. Even then, I still don't think it makes sense that a call sequence which attempts to perform a lock with an infinite timeout should have any reason to access the date_time library, especially since it apparently isn't all that fast.