Re: [boost] Performance of boost::mutex and boost::mutex::scoped_lock

Subject: Re: [boost] Performance of boost::mutex and boost::mutex::scoped_lock
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2009-06-10 13:04:55

On Wed, Jun 10, 2009 at 11:34 AM, Jonathan Franklin <
franklin.jonathan_at_[hidden]> wrote:

> On Wed, Jun 10, 2009 at 9:19 AM, Zachary Turner<divisortheory_at_[hidden]>
> 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.