This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Subtle MT problem with __gnu_cxx::hash_map
- From: Paul Dubuc <pdubuc at cas dot org>
- To: libstdc++ at gcc dot gnu dot org
- Date: Mon, 22 Nov 2004 17:43:03 -0500
- Subject: Re: Subtle MT problem with __gnu_cxx::hash_map
- Organization: Chemical Abstracts Service (CAS)
Matt Austern wrote:
>
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.
Not ONLY on a const object. You can also perform them on non-const objects.
Isn't any access that doesn't actually do a write a read-only access?
You can't use operator[] on a const hash_map. (Or on a const
map, for that matter.
True, but at least the compiler catches it when you do. operator[] can't be a
const method because it MAY do an insert. That's playing it safe where the
interface is concerned. So?
You'll be unhappy if you try to think of
operator[] on maps as a read-only operation in a multithreaded environment.)
I'll agree with you here. You're right. I guess this is an unfortunate
consequence of operator[] being BOTH a find() and an insert(). It's easy to see
the insert() as a convenient side-effect that you can avoid if you know what
you're doing. (Especially since it bears so much resemblance in its use to
array subscripting in C which doesn't have this side-effect). After all, the
programmer KNOWS he's not doing an insert in this case. And it's true that
NOTHING was actually inserted. It's just that the hash_map implementation
decided to reallocate anyway, unnecessarily, based on an arbitrary container size.
What is wrong with removing the unnecessary and wasteful reallocation and taking
the view that, if the programmer knows what he's (not) doing, let him (not) do
it without some arbitrary penalty? Can you think of any a good reason why a
container should reallocate itself (or change itself in anyway) if it's not
going to insert a new element? Wouldn't we normally call that a bug?
Instead we've got somone else suggesting that the way to fix the problem is the
much more complicated solution of making sure the use of operator[] reliably
fails in an MT environment. Please don't go through all that trouble! Let's
just stick with the letter of the law that says that since operator[] MIGHT do
an insert, it therefore IS and insert() whether it actually inserts or not. But,
whether it inserts or not, it always does a find()!
I can live with that. ;-) (I would rather live with that.)
--
Paul M. Dubuc