I'm programming in C++ on linux. My program uses two threads when one reads and writes to a shared data-structure. The data-structure is from type - Boost::bimaps::unordered_set_of .
So my question is whether I need to worry regarding any synchronizing issues. I.E, do I need to protect the read and write fro the data-structure with locks (or something like that)? Or maybe I will work fine without any use in mutexes?
Thanks.
You should work with the mutex provided by boost
http://www.boost.org/doc/libs/1_41_0/doc/html/thread/synchronization.html#thread.synchronization.mutex_concepts
In common with the standard containers, Boost.Bimap does not provide thread synchronisation. You will have to provide that yourself.
Related
While reading up on POSIX threading, I came across an example of thread-specific-data. I did have one area of confusion in my mind...
The thread-specific-data interface looks a little clunky, especially once you mix in having to use pthread_once, the various initializers, etc.
Is there any reason I can't just use a static std::map where the key is the pthread_self() id and the data value is held in the second part of the std::pair?
I can't think of a reason that this wouldn't work as long as it was wrapped in a mutex, but I see no suggestion of it or anything similar which confuses me given it sounds much easier than the provided API. I know threading can have alot of catch-22's so I thought I'd ask and see if I was about to step in... something unpleasant? :)
I can't think of a reason that this wouldn't work as long as it was wrapped in a mutex
That in itself is a very good reason; implemented properly, you can access your thread-specific data without preventing other threads from simultaneously creating or accessing theirs.
There's also general efficiency (constant time access, versus logarithmic time if you use std::map), no guarantee that pthread_t has a suitable ordering defined, and automatic cleanup along with all the other thread resources.
You could use C++11's thread_local keyword, or boost::thread_specific_ptr, if you don't like the Posix API.
pthread thread-specific-data existed before the standard library containers
thread-specific-data avoids the need of locking and makes sure no other thread messes with the data
The data is cleaned up automatically when the thread disappears
Having said that, nothing stops you from using your own solution. If you can be sure that the container is completely constructed before any threads are running (static threading model), you don't even need the mutex.
I need to make my program only one process on several platforms. I have known it can be solved with mutex on Windows, but I don't know how are other plat-forms like Linux. Mutex is not a part of C++ 03 standard though it is in C++ 0x standard. I have to wait a long time before compilers support C++ 0x well. Can boost's mutex be used for this?
Thanks in advance :)
Neither std::mutex nor boost::mutex expose the functionality of Win32 mutexes that is needed to make this work, namely system-global named mutexes, so no, you can't use either of them.
The easiest and most portable way is probably to simply create a lock file (you can write a PID to it, and then check if the process still exists to avoid locking the program out after abnormal termination). You still might need some platform-specific glue code, though.
Have a look at boost's interprocess library: http://www.boost.org/doc/libs/1_47_0/doc/html/interprocess.html
I have used a named_mutex http://www.boost.org/doc/libs/1_47_0/doc/html/boost/interprocess/named_mutex.html to make sure only one instance of my program was running.
I don't believe this can be done with a boost::mutex, but you can probably achieve the desired effect with the Boost Interprocess library.
I am working on designing a C++ server that accepts multiple different interacting clients, and I use vectors to keep track of all of them individually. However, I realized that, because of so many threads running, there's a tiny chance a vector might be read and written to at the same time by two threads. Is there a quick and safe way to add a mutex or something to them so that it will wait until all the reads are done until another function adds to it? Not doing so can mess up the protocol and maybe even crash the server.
I had an idea to create a global variable that would lock all reads to a vector, but I'm not sure if the threads can be told to mutually exclude that variable too (i.e. not change bool to false and check it as true at the same time, rendering the mechanism pointless).
I am using Windows 7 (Visual Studio 2010 Pro). Thanks for any and all advice!
The quickest solution is to replace the std::vector with a concurrent_vector. This class mimics std::vector's interface but is thread-safe for concurrent reads and writes.
However, this will make the code non-portable because the concurrent_vector class is part of the Microsoft Parallel Patterns Library and not the C++ standard library. If you want to maintain portability, you'll have to use a Boost.Mutex (since VS2010 doesn't support std::mutex) to gain exclusive access to the vector from each thread. Using a global variable to prevent concurrent access is useless.
Since you are using VS2010, you should use Concurrency::concurrent_vector. But be aware that there are limitations with this class, and is not fully thread-safe. You may use Concurrency::critical_section or Concurrency::reader_writer_lock. Reader-writer lock would give good performance when there are more reads than writes. You may also use Windows native Reader-writer locks, but they are supported only only Windows Vista and higher.
Can I use a map or hashmap in a multithreaded program without needing a lock?
i.e. are they thread safe?
I'm wanting to potentially add and delete from the map at the same time.
There seems to be a lot of conflicting information out there.
By the way, I'm using the STL library that comes with GCC under Ubuntu 10.04
EDIT: Just like the rest of the internet, I seem to be getting conflicting answers?
You can safely perform simultaneous read operations, i.e. call const member functions. But you can't do any simultaneous operations if one of then involves writing, i.e. call of non-const member functions should be unique for the container and can't be mixed with any other calls.
i.e. you can't change the container from multiple threads. So you need to use lock/rw-lock
to make the access safe.
No.
Honest. No.
edit
Ok, I'll qualify it.
You can have any number of threads reading the same map. This makes sense because reading it doesn't have any side-effects, so it can't matter whether anyone else is also doing it.
However, if you want to write to it, then you need to get exclusive access, which means preventing any other threads from writing or reading until you're done.
Your original question was about adding and removing in parallel. Since these are both writes, the answer to whether they're thread-safe is a simple, unambiguous "no".
TBB is a free open-source library that provides thread-safe associative containers. (http://www.threadingbuildingblocks.org/)
The most commonly used model for STL containers' thread safety is the SGI one:
The SGI implementation of STL is thread-safe only in the sense that
simultaneous accesses to distinct
containers are safe, and simultaneous
read accesses to to shared containers
are safe.
but in the end it's up to the STL library authors - AFAIK the standard says nothing about STL's thread-safety.
But according to the docs GNU's stdc++ implementation follows it (as of gcc 3.0+), if a number of conditions are met.
HIH
The answer (like most threading problems) is it will work most of the time. Unfortunately if you catch the map while it's resizing then you're going to end up in trouble. So no.
To get the best performance you'll need a multi stage lock. Firstly a read lock which allows accessors which can't modify the map and which can be held by multiple threads (more than one thread reading items is ok). Secondly a write lock which is exclusive which allows modification of the map in ways that could be unsafe (add, delete etc..).
edit Reader-writer locks are good but whether they're better than standard mutex depends on the usage pattern. I can't recommend either without knowing more. Profile both and see which best fits your needs.
I am writing a multi-threaded program using OpenMP in C++. At one point my program forks into many threads, each of which need to add "jobs" to some container that keeps track of all added jobs. Each job can just be a pointer to some object.
Basically, I just need the add pointers to some container from several threads at the same time.
Is there a simple solution that performs well? After some googling, I found that STL containers are not thread-safe. Some stackoverflow threads address this question, but none that forms a consensus on a simple solution.
There's no built-in way to do this. You can simply use a lock to guard one of the existing container types. It might be a better idea to have each thread use it's own container, then combine the results together in the end.
Using a mutex or similar synchronization primitive to control access to a linked list is not very difficult, so I'd recommend you try that first.
If it performs so poorly that you can't use it, try this instead: give each thread its own job queue, and have the job consumer check all the queues in turn. This way each queue has only one reader and one writer, so a lock-free implementation is relatively straightforward. By this I mean it may exist for your platform; you should not attempt to write it yourself.