Re: Subtle MT problem with __gnu_cxx::hash_map

[Matt Austern <austern at apple dot com>]

On Nov 19, 2004, at 12:38 PM, Lothar Werzinger wrote:

> On Friday 19 November 2004 12:30, Matt Austern wrote:
> > On Nov 19, 2004, at 12:21 PM, Paul Dubuc wrote:
> > > There's a subtle thread safety problem with hash_map that was found 
> > > in
> > > our testing recently.  It's understood that operator[] is a non-const
> > > method since it can insert an element into a container if one is not
> > > found with the given index.
> > >
> > > In our case we were using operator[] to access a hash_map that had
> > > been fully populated.  Each index we were using did have an entry in
> > > the hash_map.  So we were accessing elements in the map with
> > > operator[] using multiple threads thinking that this would be a 
> > > thread
> > > safe, const operation.  This is implied by the statement 
> > > "simultaneous
> > > read accesses to to shared containers are safe" in the SGI STL user's
> > > guide (http://www.sgi.com/tech/stl/thread_safety.html).
> >
> > But operator[] isn't read access.  It's defined to be equivalent to a
> > certain form of insert().
>
> If one can be sure that the elements that are accessed using 
> operator[] do
> exist, I would also tend to assume it should behave like a read only 
> access.

But it isn't.  Read-only accesses are things you can perform on a const
object.  You can't use operator[] on a const hash_map.  (Or on a const
map, for that matter.  You'll be unhappy if you try to think of 
operator[]
on maps as a read-only operation in a multithreaded environment.)

			--Matt