--- In Boost-Users@y..., Herve Blanc 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

--- In Boost-Users@y..., Herve Blanc wrote:

bill_kempf wrote:

...

--- In Boost-Users@y..., Herve Blanc 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