views:

2854

answers:

6

Does anyone know where I can find an implimentation that wraps an STL map and makes it thread safe? When I say thread safe I mean that it offers only serial access to the map, one thread at a time. Optimally, this map should use only STL and or boost constructs.

+1  A: 

The boost shared_mutex would provide the best multiple reader/single writer approach to wrapping a standard map given your constraints. I don't know of any "pre-built" implementations that marry these two since the task is generally trivial.

Joe
The task is far from trivial, at least to do efficiently, which is why you won't find any implementations.
anon
Okay, perhaps "trivial" is the wrong word. It is not HARD to do, at least in the specific context you are working on (unless you have some very specific requirements).
Joe
A: 

This is up to the application to implement. A "thread-safe" map would make individual calls into the map thread-safe, but many operations need to be made thread-safe across calls. The application that uses the map should associate a mutex with the map, and use that mutex to coordinate accesses to it.

Trying to make thread-safe containers was a mistake in Java, and it would be a mistake in C++.

Dan Breslau
+8  A: 

It is generally not a good idea for collection classes to provide thread-safety, because they cannot know how they are being used. You will be much better served by implementing your own locking mechainisms in the higher level constructs that use the collections.

anon
Why is it not a good idea? Can you point me to some articles? I just don't understand why Java, C#/VB (.NET), and C++ all have libraries for concurrent collections if they're a bad idea. The libraries respectively are: java.util.concurrent, System.Collections.Concurrent (.NET 4.0), and Intel's Threading Building Blocks. Is the argument that you simply take a performance hit by using these libraries? I know some of the collections always return a snapshot "copy" for iteration and such, so I can see how that would be slower.
Chris Andrews
I don't understand why those libraries have thread-safe collections either.
anon
He's not asking for a thread-safe collection class. He's wanting a "higher level construct" as you've talked about that "wraps" the implementation.
Matt H
A: 

Try this library

http://www.codeproject.com/KB/threads/lwsync.aspx

It is implemented in a modern c++ policy based approach.

Here is some cut from the link to show the idea with the 'vector' case

typedef lwsync::critical_resource<std::vector<int> > sync_vector_t;
sync_vector_t vec;

// some thread:
{
   // Critical resource can be naturally used with STL containers.
   sync_vector_t::const_accessor vec_access = vec.const_access();
   for(std::vector<int>::const_iterator where = vec_access->begin();
         where != vec_access->end();
         ++where
        )
   std::cout << *where << std::endl;
}

sync_vector_t::accessor some_vector_action()
{
   sync_vector_t::accessor vec_access = vec.access();
   vec_access->puch_back(10);
   return vec_access;
   // Access is escalated from within a some_vector_action() scope
   // So that one can make some other action with vector before it becomes
   // unlocked.
}

{
   sync_vector_t::accessor vec_access = some_vector_action()
   vec_access->puch_back(20);
   // Elements 10 and 20 will be placed in vector sequentially.
   // Any other action with vector cannot be processed between those two
   // push_back's.
}
Mykola Golubyev
+3  A: 

Does not meet the criteria that you have specified, but you could have a look at the TBB containers. There is so called concurrent_hash_map which allows multiple threads to access concurrently the data in the map. There are some details, but everything is nicely documented and can give you an idea of the "concurrent container". Depending on your needs this might be totally inappropriate...

Anonymous
+1  A: 

You might look at Thread Safe Template Library

Jay