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
1) Higher level threading constructs, a message queue, worker pool and
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
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.
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?
> -----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.
> 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:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk