I am new to multi-threading and I am trying to simply make some std:lists thread-safe. Would it be enough to do mutex.lock() and mutex.unlock() whenever an item is being added or removed to the lists? Again, I am only trying to make them thread-safe.
Thanks
Generally, yes. If every thread/path that modifies or reads the list locks the same mutex before doing so, then access to the list can be considered thread safe. Note that caveats apply if someone holds on to iterators, references or pointers to list items outside the scope of the lock.
A threadsafe function protects shared resources from concurrent access by locks. Thread safety concerns only the implementation of a function and does not affect its external interface.
No, they're not thread-safe.
++ is not defined as thread-safe.
You must protect all access to the list in order to be safe. While reading from a list without a lock will not corrupt the list, if the list is modified while another thread is reading from it, either thread could become corrupt (i.e. crash, or produce incorrect results).
You must hold the lock for the entire span of code that you expect the contents to be stable for. If another thread can erase or reorder any element at any time, then this includes any time you have live iterators to its contents. If there are restrictions as to which threads can manipulate which elements, the locking requirements can be relaxed with respect to holding live iterators.
Using std::lock_guard can help make sure you manage the lock correctly. Just create an instance of it at the beginning of any scope that will manipulate your list, and at the end of the scope it will automatically unlock, even if the scope exits via exception.
Note that C++ does not define thread-safe, but defines data race which is a condition that occurs when multiple threads access the same object and at least one of them is a writer.
You can use a mutex to make member functions of std::list<>
data race free. You can even do that for any arbitrary object with Wrapping C++ Member Function Calls technique by Bjarne Stroustrup. This is known as internal locking, meaning that the object maintains its own mutex.
This method does not make data race free leaked references to the internal state of the object, such as references, pointers and iterators. For example, when you iterate over the list you do not want another thread to invalidate your iterator by removing the element, hence you will have to keep the mutex locked till the iteration has completed.
Also, in many useful scenarios it is more than just one object that needs to be changed atomically. In this case you need one mutex that serializes access to multiple objects.
Generally, yes. If every thread/path that modifies or reads the list locks the same mutex before doing so, then access to the list can be considered thread safe.
Note that caveats apply if someone holds on to iterators, references or pointers to list items outside the scope of the lock. In that case you are no longer safe.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With