Re: std::deque Thread Saftey Situtation
On Sep 3, 3:00 am, Jerry Coffin <jcof...@taeus.com> wrote:
In article <e78577f0-da15-42c9-96ad-63e4bc2c7638
@w7g2000hsa.googlegroups.com>, james.ka...@gmail.com says...
[ ... ]
I'd generally avoid it. Wrapping it works, but presents
trade offs I rarely find useful.
I find the trade off of using tried and tested code, rather
than having to write it myself, useful. (Of course, if you
already had your basic queue working before STL came
along...)
The problem is that the part that's tried and tested is
downright trivial compared to what's not -- and at least from
the looks of things in this thread, using that tried and
tested code makes it even more difficult to get the hard part
right, so I suspect it's a net loss.
I don't see where the actual implementation of the queue would
affect the rest, unless you're doing some tricky optimizations
to make it lock-free. (std::deque is obvious not lock-free; you
need locks around the accesses to it.) And your code didn't
seem to be trying to implement a lock free queue.
On the other hand, since I work under Unix, my queues used a
condition rather than semaphores, so the issues are somewhat
different, but basically, all I did was copy the code for the
wait and send from Butenhof, and stick an std::deque in as the
queue itself. You can't get much simpler.
...and yes, if memory serves, my queue code was originally
written under OS/2 1.2 or thereabouts (originally in C, which
still shows to some degree).
Which explains why you find the implementation of the queue so
simple:-). Most things are simple when you've been maintaining
them for so many years. My experience is that unless you
implement the queue trivially, using something like std::list,
getting the border conditions right isn't always that obvious
(but once you've got them right, the code is trivial).
[ ... ]
In the end, the main gain was that I didn't have to write any
code to manage the queue. And that other people, maintaining
the software, didn't have to understand code that I'd written.
I suppose it might make a difference, but I have a hard time
believing that anybody who could understand the semaphore part
would have to pause for even a moment to understand the queue
part. Duplicating it without any fence-post errors might take
a little longer, but even that's still not exactly rocket
science.
Well, my own implementation uses condition variables, rather
than semaphores. But it's really, really simple. FWIW
(modified to use Boost, rather than my home build classes, and
with support for handling timeouts removed):
class QueueBase
{
public:
QueueBase() ;
~QueueBase() ;
void send( void* message ) ;
void* receive() ;
bool isEmpty() const ;
private:
boost::mutex mutex ;
boost::condition_variable
cond ;
std::deque< void* > queue ;
} ;
template< typename T >
class Queue : public QueueBase
{
public:
~Queue()
{
while ( ! isEmpty() ) {
receive() ;
}
}
void send( std::auto_ptr< T > message )
{
QueueBase::send( message.get() ) ;
message.release() ;
}
std::auto_ptr< T > receive()
{
return std::auto_ptr< T >(
static_cast< T* >( QueueBase::receive() ) ) ;
}
} ;
QueueBase::QueueBase()
{
}
QueueBase::~QueueBase()
{
assert( queue.empty() ) ;
}
void
QueueBase::send(
void* message )
{
boost::unique_lock< boost::mutex >
lock( mutex ) ;
queue.push_back( message ) ;
cond.notify_one() ;
}
void*
QueueBase::receive()
{
boost::unique_lock< boost::mutex >
lock( mutex ) ;
while ( queue.empty() ) {
cond.wait( lock ) ;
}
void* result = queue.front() ;
queue.pop_front() ;
return result ;
}
bool
QueueBase::isEmpty() const
{
boost::unique_lock< boost::mutex >
lock( mutex ) ;
return queue.empty() ;
}
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34