boost::unordered_map thread safety

This is a simple question, but a quick search didn't turn up any answers. Is it safe for multiple readers to access a boost::unordered_map concurrently? -Kenny Riddile

2008/11/10 Kenny Riddile
This is a simple question, but a quick search didn't turn up any answers. Is it safe for multiple readers to access a boost::unordered_map concurrently?
Yes, as long as nothing modifies it (and the key and mapped object, hash function and key predicate are appropriately safe, of course). This is the same as any STL container. Daniel

Daniel James wrote:
2008/11/10 Kenny Riddile
: This is a simple question, but a quick search didn't turn up any answers. Is it safe for multiple readers to access a boost::unordered_map concurrently?
Yes, as long as nothing modifies it (and the key and mapped object, hash function and key predicate are appropriately safe, of course). This is the same as any STL container.
Daniel
I could be wrong, but I don't think the standard says anything about the thread safety of STL containers, so it's implementation-specific. Still, it's good to know that using boost::unordered_map this way is ok.

On Mon, Nov 10, 2008 at 2:43 PM, Kenny Riddile
I could be wrong, but I don't think the standard says anything about the thread safety of STL containers, so it's implementation-specific.
The standard says nothing of thread safety. However, 17.4.4.5 says "Which of the functions in the C++ Standard Library are not reentrant subroutines is implementation-defined." So at least wrt reentrancy it's implementation defined. Jon

Jonathan Franklin wrote:
On Mon, Nov 10, 2008 at 2:43 PM, Kenny Riddile
mailto:kfriddile@yahoo.com> wrote: I could be wrong, but I don't think the standard says anything about the thread safety of STL containers, so it's implementation-specific.
The standard says nothing of thread safety. However, 17.4.4.5 http://17.4.4.5 says "Which of the functions in the C++ Standard Library are not reentrant subroutines is implementation-defined." So at least wrt reentrancy it's implementation defined.
In the context of unordered containers it seems appropriate to consider the direction the standard is going. The most recent draft N2798 has updated some parts of the library introduction to take care of this. In 17.6.4.10 [res.on.objects] we have: "The behavior of a program is undefined if calls to standard library functions from different threads may introduce a data race. The conditions under which this may occur are specified in 17.6.5.7." and in 17.6.5.7 [res.on.data.races] we find several added/updated paragraphs. Please read details in: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf - Daniel
participants (4)
-
Daniel James
-
Daniel Krügler
-
Jonathan Franklin
-
Kenny Riddile