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