Re: thread & containers

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-07-30 16:10:30

--- In Boost-Users_at_y..., Herve Blanc <blanc_at_s...> wrote:
> bill_kempf wrote:
> 
> >  --- In Boost-Users_at_y..., Herve Blanc <blanc_at_s...> wrote:
> > > Is there anything available or coming in boost::thread to wrap 
STL
> > containers
> > > into thread safe containers?
> >
> > No.
> >
> > > If not, any advice for coding those wrappers 
efficiently/elegantly
> > or not doing
> > > that?
> >
> > Trying to do this is generally a bad idea.  Using an internal 
mutex
> > to protect the class will only allow you to synchronize at the 
method
> > call level, and most user code will need synchronization around
> > multiple such calls not a single call.  Example:
> >
> > my_thread_safe_vector[0] += some_value;
> > if (my_thread_safe_vector[0] > 100)
> >    my_thread_safe_vector[0] = 100;
> >
> > The above code is full of race conditions, even if
> > my_thread_safe_vector uses a mutex internally.
> >
> > > If not again, why and how do you deal with the problem then?
> >
> > Use an external mutex to achieve the proper lock granularity.
> > Example:
> >
> > boost::mutex::scoped_lock lock(my_mutex);
> > my_vector[0] += some_value;
> > if (my_vector[0] > 100)
> >    my_vector[0] = 100;
> >
> > There's no race in the above since the external mutex and lock 
insure
> > the proper granularity for the three calls to the container 
methods.
> >
> > Bill Kempf
> >
> >
> The "Multithreading and the C++ Type System" article by Andrei 
Alexandrescu
> (available @
>  http://www.informit.com/isapi/product_id~%7BE3967A89-4E20-425B-
BCFF-B84B6DEED6CA%7D/content/index.asp
> )
> provides a generic solution to your scenarios as well... the kind 
of answer I
> was looking for, am I missing something?

Not really missing anything.  I've employed similar techniques in my 
own code, though there are some interesting design choices here that 
I may find a way to add to Boost.Threads.  I thought what you were 
wanting was something along the lines of full replacements that used 
internal locking or something along the lines of the solution in this 
article where you pass in locks.  The first is a bad idea, while the 
second is out of scope for the library.  I have, however, been 
contemplating the inclusion of a locking_ptr<> (a concept I'll 
attribute to Bjarne, though I've seen others discuss this concept as 
well and really don't know who was first), but with the ability to 
hoist the locking level up for larger granularity.  The result would 
be something similar to the ExternallyLocked template from this 
article.  I'm still working out some of the design details, and this 
has a rather low priority right now, but I am playing with the idea.

Bill Kempf