STL Thread Safety

STL Thread Safety

• 愛青蛙

  Two things have to happen here:

  1) The C++ Committee has to decide on what the best threading model for C++ is - this is by far the largest single work-item that is currently under-discussion for the next revision of the C++ Standard.

  2) Once the overall threading model has been decided then it needs to be integrated into the rest of the C++ Standard - and by this I largely mean the Standard C++ Library. For the containers what I suspect will happen is  that there will be a separate set of thread-safe containers and that the current containers will remain pretty much as they are. Why I believe that this will happen is that even with the best threading model possible there will still be a certain overhead that is imposed on the user - and there will be users who are a) happy with the current containers and b) won't accept any additional overhead - so the C++ committee will create a new set of containers (std::thread_safe ).

  In anycase I don't see Microsoft shipping their own thread-safe version of the SCL containers before the C++ Committee has finalized the design.

  
  
  

• John Dunn

  mmoo9154 wrote:

  For instance, it would be (fairly) trivial, and immensely useful if std::queue was safe to insert from one thread and extract from another without synchronization.

  Mixing synchronization with those containers would introduce a bucket of problems.

  • It would make portable / semi-portable STL implementations a lot harder to maintain.
  • How can one judge which synchronization approach is best fit for any use of say a queue While one user would like read / write synchronization, other uses may be more fit for schemes such as write / write, read / read. One size is unlikely fit all; so should the STL introduce extensive policy classes to deal with this (IMHO: no)
  • It's hard to tell which expectations a user will have of such a framework. While some are content with the simple forms of synchronization, others may anticipate destruction synchronization, or even support for concurrent iteration and structural changes (e.g. one thread erases an element, another iterates -- perhaps breaking the iterator). It's pretty clear that it's close to impossible to deal with all kinds of synchronization from within the structure itself.
  • It's likely to be horribly inefficient, due to unnecessary synchronization in some cases and multiple synchronization in other.

  Why would a largely algorithmic library deal with system dependant constructs more than absolutely necessary

  
  
  

• Niro

  Einaros,

  I'm talking about the day (coming soon) when threads *are* standard. (Think pthreads, or better, Boost.Threads.) When threads are as much a part of STL as containers, iostreams, or locales, portability will be a non-issue because of the underlying thread library. Thread safety won't need to be system dependent.

  On how a library writer (or a standardization committee) decides what implementation is “best fit”, it's a tough job, but they're up to the challenge. ;o) In all likelihood, they would introduce a new concept for the specialized container. Existing STL examples of resolving the tension you appear to be worried about would be the introduction of vector, list, slist, stack, and queue. Each of these have their own particular characteristics, optimizations, and guarantees.

  The main discriminator of whether something is included in a GP library is its utility. Queues are widely used to efficiently decouple asynchronous processes. Assuming you’re sitting in front of your Windows box right now, you are using scores of them. Inter-process queues seem to meet the utility requirement, and the reason the system uses queues so extensively is because they are very efficient.

  You said "it’s hard to tell which expectations a user will have of such a framework." In fact, it’s quite easy. Users will (should) expect whatever expectations are documented to be supported by the standard implementation. For example, std::list documents constant time insertion and removal of elements while std::vector only guarantees constant time insertion at the end.

  Your final bullet is the whole reason I mentioned this request here. It shouldn’t be “horribly inefficient” to have a thread safe queue. Properly written queues can be completely thread safe without the need for (blocking) synchronization at all. Two common implementations are using a circular buffer, or a singly linked list. Both of these can be implemented with no blocking required as long as the system provides atomic reads and atomic writes for pointer values.[1] Frankly, most modern OS’s (and even a large fraction of embedded systems) provide this requirement for free.[2]

  An inter-process queue seems to present the classic signature of something that belongs in a standard library: something that is widely deployed, and by implication extremely useful, but non-obvious/non-trivial to code correctly and to code efficiently. I sure hope the Visual C++ Library Team considers including one.

  -MM

  [1] The implementation would require a critical section to support resizing, but would be non-blocking otherwise.

  [2] With atomic pointer exchange, I believe it’s possible to support multiple simultaneous readers as well.

  
  

• Brandon Bloom

  This is probably a better location. C# knows nothing about the Standard C++ Library.

  The current C++ Standard Library - like the rest of the current C++ Standard - knows nothing about threads and thread-safety - it assumes a single threaded world. This may change in the next revision of the C++ Standard but for now if you are using the C++ Standard Library in a multithreaded environment then you, the programmer, are responsible for handling all threading issues.

  
  
  

• Eudi

  stl is a gift among c++ developers. there is no need for thread-safe stl as stl is about abstraction, not specific to anything. it is not impossible, although not easy, to correctly make the stl thread-safe.
  
  better to enhance stl with more features and algorithms.
  
  Kuphryn
  
  

• Juergen Lorenz

  This was moved here by a moderator named ahmedilyas. This doesn't look like a reasonable place to discuss the C++ Standard Library for all versions of Visual Studio (IMHO).

  ahmedilyas, is this really the right place

  
  

• IS dude

  mmoo9154 wrote:

  I'm talking about the day (coming soon) when threads *are* standard. (Think pthreads, or better, Boost.Threads.) When threads are as much a part of STL as containers, iostreams, or locales, portability will be a non-issue because of the underlying thread library. Thread safety won't need to be system dependent.

  IMHO it's unlikely to come anytime soon, simply because standardizing a largely system dependant technology is inevitably complex, in addition to not being very suitable to integrate in the algorithmic classes that are STL. Wrapping key STL parts is a much more feasible solution, but again, one would be left with the restrictions caused by the language.

  mmoo9154 wrote:

  You said "it’s hard to tell which expectations a user will have of such a framework." In fact, it’s quite easy. Users will (should) expect whatever expectations are documented to be supported by the standard implementation. For example, std::list documents constant time insertion and removal of elements while std::vector only guarantees constant time insertion at the end.

  That's not entirely true. The very reason for this forum to exist is the fact that many, if not most, users are poor at reading documentation (no offence intended). As long as you can't promise full thread safety, there's really no way of not introducing a bunch of new problems and errors into both existing and future software. A user which doesn't want or need all the responsibilities left upon him by C++ and STL, he is better off looking to languages such as C#, which has a much better chance of providing the proper safety -- without tearing the language apart.

  mmoo9154 wrote:

  Your final bullet is the whole reason I mentioned this request here. It shouldn’t be “horribly inefficient” to have a thread safe queue. Properly written queues can be completely thread safe without the need for (blocking) synchronization at all. Two common implementations are using a circular buffer, or a singly linked list. Both of these can be implemented with no blocking required as long as the system provides atomic reads and atomic writes for pointer values.[1] Frankly, most modern OS’s (and even a large fraction of embedded systems) provide this requirement for free.[2]

  It would be inefficient to be locked to a synchronized queue in a single threaded environment. The best performing structure will, without a doubt, be the one tailored to fit the very predicament in which it is used. Unless policies are introduced to control this, many will simply not bother to use the library at all.

  
  
  

• Seefer

  Jonathan,

  Thanks for the quick reply. Although there is no standardized way to create or manage threads under STL, there is a recognition of an underlying threading model.[1] Without this, the STL would be unusable since there would be no way to synchronize access to resources shared by the underlying implementation (e.g. allocators, std file IO, and and class statics).

  When the Visual C++ Compiler Team gets around to implementing more explicit thread behavior (or even better, influencing the standard directly), it would be *very* useful if the abstractions were considered from the single writer, multiple reader perspective.

  For instance, it would be (fairly) trivial, and immensely useful if std::queue was safe to insert from one thread and extract from another without synchronization.

  -MM

  [1] http://msdn2.microsoft.com/en-us/library/c9ceah3b.aspx

  
  
• STL Thread Safety