RE: [boost] Re: rw_mutex changes

From: Hurd, Matthew (hurdm_at_[hidden])
Date: 2003-10-27 02:50:20

Hi Anthony,

> -----Original Message-----
> From: Anthony Williams [mailto:anthony.williamsNOSPAM_at_[hidden]]

> "Hurd, Matthew" <hurdm_at_[hidden]> writes:
> > A further note:  The exception characteristics for a message queue are
> > particularly interesting.  Normally, as per exceptional c++, you'd
> separate
> > the top and pop part, or head and remove_head, for the reasons discussed
> in
> > Sutter's book.  However, in a threaded case, you want this as an atomic
> op
> > and you have an exception problem AFAICT.  Not sure what the answer is
> here
> > with these competing concerns.  Any thoughts?
> 
> Have the queue return an object that locks the queue for the duration of
> its
> existence, which contains functions for top and pop.
> 
> e.g.
> 
> template<typename T>
> class MessageQueue
> {
> public:
>     class MessageQueueQueryObject: boost::noncopyable
>     {
>     public:
>         T top() const;
>         void pop();
>     };
> 
>     std::auto_ptr<MessageQueueQueryObject> query();
> };
> 
> MessageQueue<std::string> queue;
> std::string var;
> {
>     std::auto_ptr<MessageQueueQueryObject> queryObj(queue.query());
>     var=queryObj->top();
>     queryObj->pop();
> }
> 
> Anthony

Thanks.

That will work.  I'll have a think about this some more... I'm particularly
interested in doing it in a way that is compatible with the single-threaded
no-locking case and multi-threaded locking case with minimal overhead to the
single threaded thinking...  Obviously here the query objects add a fair bit
of semantic overhead to a generic class for the single threaded case where
they are not needed.

A policy class could take care of the overhead performance wise but not the
keystroke side of things...

This seems no worse than the null_synch / rw_synch approach where you have
to code to the rw_synch target where the null_synch elides the
synchronization.

I think that perhaps this is the only way...

But still, it would be nice if a pop and top could be combined into a single
atomic operation from a performance point of view, but the exception
specifications are toasted...

Thanks and regards,

Matt Hurd