RE: [boost] Re: rw_mutex changes

From: Hurd, Matthew (hurdm_at_[hidden])
Date: 2003-10-23 18:28:58

Yep.  We agree then about the consistency.  

It would be nice if the thread library made a bit more progress, but it is
very useful in its current state.

I can think of five main things I'd like to see, some of which I can
contribute to:

1)	Higher level threading constructs, a message queue, worker pool and
the like.

2)	Atomic operation abstractions.  Simple atomic ops as static methods
in a class.

3)	A policy way of introducing null_synch, rw_synch, standard_synch
kind of policies to classes.  Code to rw and get the others by simply
changing policy.  

4)	A way to approach external _and_ internal mutual exclusion.
        4a)   external mutex / monitor and non-locking method calls
        4b)   locking or synchronized method calls

5)	Collection exclusion notions where there may be a mutex per
collection, a mutex per node or a collection of mutexes shared or something
more exotic.  I regularly use all the first three three approaches.  Perhaps
this makes sense to include with item 3 or perhaps it is separate.

I'm mulling this stuff over at the moment and have some stuff I've already
done that is pretty unsatisfactory but might be a start.  

Any interest?

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?

Regards,

Matt Hurd

> -----Original Message-----
> From: Michael Glassford [mailto:glassfordm_at_[hidden]]
> Sent: Thursday, 23 October 2003 10:52 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: rw_mutex changes
> 
> I have no problems with the shared/exclusive terminology, but with the
> inconsistency. In my mind, either the shared/exclusive constants should be
> changed to read/write, or the class and function names should be changed
> from read/write to shared/exclusive. Since the former change involved far
> fewer edits, and since rw_mutex and rw_lock seem to be more traditional
> terminology, I decided on the former change.
> 
> Not that the choice is really mine since none of the original classes were
> written by me and I'm not the maintainer of the Boost.Threads library--I'm
> just another vote.
> 
> Mike
> 
> 
> Hurd, Matthew wrote:
> > Just one small point...
> >
> >> Rename rdlock() member function to read_lock() and wrlock() to
> >> write_lock()?
> >
> > I'd rather see exclusive and shared retained.  There maybe times you
> > wish
> > for exclusive reading and taking a write lock for exclusive reading
> > is not
> > so intuitive.
> >
> > Recursive exclusive locks would help too.  Perhaps through a
> > rw_recursive_mutex to keep things orthogonal.
> >
> > Regards,
> >
> > Matt.
> > _______________________________________________
> > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boost
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost