Multiple processes pushing elements to list STL C++

Question

I have multiple preforked server processes which accept requests to modify a shared STL C++ list on a server. Each process simply pushes a new element at the end of the list and returns the iterator.

I'm not sure how should each process attempt to acquire lock on the list? Should it be on entire object or are STL Lists capable of handling concurrency since we're just pushing an element at the end of the list?

Answer 1

Assuming you meant threads rather than processes you can share the STL containers but you need to be careful with respect to synchronization. The STL containers are threads safe to some extend but you need to understand the thread safety guarantees given:

1. One container can be used by multiple readers concurrently.
2. If there is one writer for a container, there shall neither be concurrent readers nor concurrent writers.
3. The guarantees are per container, ie, different containers can concurrently be used by threads without need of synchronization between them.

The reason for these restrictions is that the interface for the containers is geared towards efficient use within one thread and you don't want to impeded the processing of an unshared container with the potential of being shared across threads. Also, the container interface isn't suitable for any sort of container maintained concurrency mechanism. For example, just because v.empty() just returned false it doesn't mean that v.pop() works because the container can be empty by now: If there were internal synchronization any lock would have been released once empty() returned and the container can be changed by the time pop() is called.

It is relatively easy to create a queue to be used for communication between different threads. It would use a std::mutex and a suitable instantiation of std::condition_variable . I think there is something like this proposed for inclusion into the standard but it isn't, yet, part of the standard C++ library. Note, however, that such a class would not return an iterator to the inserted element because by the time you'd access it, the element may be gone again and it would be questionable what the iterator is used for anyway.

Answer 2

The standard library containers offer no automagic protection against concurrent modifications, so you need a global lock for every access of the queue.

You even have to be careful with the iterators or references to list elements, since you may not necessarily know when the corresponding element has been removed from the list.

Answer 3

The mechanism for doing this kind of synchronisation between multiple processes requires that the developer deal with several issues. Firstly whatever is being shared between the processes needs to be set up outside of them. What this usually means in practice is the use of shared memory .

Then these processes need to communicate with each other with respect to accessing the memory being shared. After all if one thread starts to work on a data structure being shared, but gets swapped out before completing the operation it will leave the data inconsistent.

This synchronisation can be done using operating system constructs such as semaphores in linux, and will allow competing processes to coordinate.

See This for linux based IPC detail See This for Windows based IPC detail

For some reference you can use the Boost.Interprocessdocumentation which provides a platform independent implementation of IPC mechanisms.