Re: std::string bad design????
Peter Dimov wrote:
Le Chaud Lapin wrote:
James Kanze wrote:
The problem is that you don't know what the classes do. You use
an std::map, for example; how do you know that it doesn't use
static memory (e.g. in its allocators) in the implementation.
Unless std::map is thread-safe, you cannot use it in a
multithreaded application.
There is a fundamental difference in expectations here. I do not
expect any state, not even a simple int, to be thread-safe unless I
make it thread-safe;
int x; // not thread-safe
You almost certainly do; I can state that even though you don't explain
your use of "thread safe", an ambiguous term.
For example, you expect that you can operate on x from thread 1 while
thread 2 is operating on another int. (1)
It's also reasonable to expect that two threads can read x
simultaneously. (2)
Just for the record, although I think that there is a consensus
in the committee in favor of (2) (and Posix requires it), the
formal guarantees of g++ still do not provide it, or at least
they didn't the last time I looked (something like version 3.3
or 3.4, I think). The formal statement of g++ was that
synchronous access to a shared object was not supported, period.
"Not thread safe" essentially means that you can't use an int in a
multi-threaded program, and we know this to not be true.
Just a nit, but I'd formulate it slightly differently: "not
thread safe" means that you don't know how to use an int in a
multi-threaded program. Thread safety is first and foremost a
(written) contract. (The case of int is usually covered by a
generic contract, e.g. the Posix contract.)
Your container (from your description) violates (2) but probably not
(1), even though you describe its level of thread safety as "none". STL
containers obey both (1) and (2) (sometimes referred to as "basic"
thread safety).
More correctly: the SGI implementation of the STL obeys both (1)
and (2). The g++ guarantee is:
All library objects are safe to use in a multithreaded
program as long as each thread carefully locks out access by
any other thread while it uses any object visible to another
thread, i.e., treat library objects like any other shared
resource. In general, this requirement includes both read
and write access to objects; unless otherwise documented as
safe, do not assume that two threads may access a shared
standard library object at the same time.
Note that it explicitly excludes (2). (It's also a little
misleading when it says "like any other shared resource": under
Posix, at least, concurrent read only access is allowed for
shared resources.)
In practice, the issue is further confused by the fact that much
of the g++ code for the STL derives from the SGI code, and does
in fact give the SGI guarantees. In addition, the examples (in
5.6 of the libstdc++-v3 FAQ) only concern mutating functions.
It is precisely because of this sort of confusion that it is so
important that threading be standardized. I can easily wrap my
invocations to the threading primitives, or use a portable
library like boost::threads, but I cannot easily modify my code
to adapt to different guarantees; if my code was written with
the idea that (2) holds, then it could require a major rewrite
to make it work with g++. Worse: unless I'm aware of the issue,
I may not even realize that a rewrite is necessary. Most of the
g++ library actually does allow (2), and the cases where there
are actually problems are very difficult to detect, and will
almost certainly slip through any test cases I'll have written.
For those interested, you might want to look at the discussions
surrounding bug 21334 in libstdc++. It got fairly hot, but if
nothing else, it makes it clear just how unsure is can be with
regards to what is guaranteed. There are at least two distinct
issues involved with that bug report, which the standard must
address:
-- What general guarantees are given, and in particular, is
your (2), above, required? (I think that there is a
consensus in the committee for requiring (2), but it's hard
to be sure; I don't think that there's been an actual vote
as yet.)
-- What constitues a "mutating access"? In particular, if you
do something like:
std::find( s.begin(), s.end(), whatever ) ;
or:
if ( s[ 0 ] == 'a' ) ...
and s is a non-const object (so the non-const versions of
begin() or operator[] are called), does this constitute a
"mutating access"? (I can't see any reasonable way it could
be, but I know that some others disagree. I've called a
non-const member function, so its a "mutating access". But
some others seem to disagree. Particularly in the case of
std::basic_string, since the function calls may invalidate
iterators, etc. The obvious solution is for the standard to
pronounce one way or the other.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]