Re: [boost] Re: Boost.Threads: Do we need all those mutexes?

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2004-07-08 17:51:01

If boost is considering an alternative design I would like to suggest
that an approach is taken where the synchronisation is parameterizable
(is that a word?) so one can write to an exclusive/shared interface
(commonly referred to as read/write) and substitute in a recursive,
standard (just exclusive) or no_synch policy and the code will still
work.

This allows you to write to an shared/exclusive (r/w) style and have
you code automatically usable in all the other modes.

Also being able to write code that works in blocking and non-blocking
(try or timed) mode is useful.

I current use both these approaches with my code by wrapping the
current boost libs and the thread_dev rw_mutex.  Though my approach
needs work.

W.r.t to shared to exclusive (r to w) promotion, this will always be
non-blocking with non-shared policies as you have the exclusive lock. 
In fact it is unnecessary and may be elided for non-shared cases. 
Same goes for exclusive to shared (r to w).

This allows you to write better generic designs.

Further to this, I use an approach, where I have locking and
non-locking methods for interface access with mutex exposure.  This
allows efficient grouped operations, safe automatic use, and dual use
objects where sometimes they are in a state that needs locking and
sometimes not.  My design here is unsatisfactory and I can see better
ways of doing this.

For the mythical boost policy pointer, I would also like to see this
approach.  The current shared_ptr performance gives me grief.  As has
been pointed out in another thread by others, because of the mutex (or
double atomic ops if it was safe to change to this) it is half the
speed of a normal single interlocked increment based pointer.  Also,
for many states in multi threaded libraries you don't care about the
thread safety and thus the enormous cost (yes enormous is not
understating it) of an atomic op or critical section is unfortunate.

Regards,

Matt Hurd.