------- Additional Comments From jkanze at cheuvreux dot com  2005-05-04 12:46 
-------
Subject: Re:  Lack of Posix compliant thread safety in std::basic_string


|> [...]

|> | This bug report came about because of a discussion in a news
|> | group.  Basically, I said to watch out for std::string with g++
|> | if you are in a multithreaded environment.  I don't remember my
|> | exact words, but I'm pretty sure that the gist would have been
|> | that the g++ implementation of std::string does not behave as
|> | one might expect.  I said it in a newsgroup, rather than making
|> | a bug report, because I knew of the text in the FAQ (or
|> | something similar), and I was convinced that no one here would
|> | consider it an error.  Gaby suggested otherwise; that if I could
|> | describe a case where the code could fail, although no thread
|> | modified the string, I should report it as a bug.  So we're
|> | here, and I'm getting hounded because my email contains trailers
|> | which I can do nothing about:-).  I was inordinately pleased by

|> James --
|>   I think you can abstract over the remark about your mailer, however
|> annoying it is :-)

I did put a smiley behind the complaint.  I can imagine that all
that garbage that gets added is as annoying to others as my
being told to do something about it is to me.  All I can say is
that it annoys me too, and that I"d get rid of it if I could.

|> As of the model behind the implementation of std::string, I do not
|> think we have reached an agreement within the maintainers that it is
|> actually right and your description is wrong.  I'm of the opinion
|> that we're reached a point where it causes so much conofusion that
|> there must be something wrong with it.  Having listening to either
|> sides and looking at the codes, I'm inclined to consider your report
|> valid -- however "hypothetical" my fellow maintainers may consider
|> it :-)  Concurrent read accesses should be guaranted, following POSIX.

All I really ask is that the problem be recognized.  As I said,
it only affects certain specific cases, and there are acceptable
work arounds.  If the doc says explicitly, we're doing something
different here, I can live with that -- I would suppose that
there were some good technical reasons (or possibly
non-technical -- the world isn't 100% controlled by technology
yet) for it.

Responses along the lines of "it's only hypothetical", or
"you're not playing the game according to our rules", are not
helpful.  They're not helpful because I know that already.

The window of vulnerability is exceedingly small, which means
that creating a test case which reliably fails is exceedingly
difficult.  From your comments in the newsgroup, I was fairly
sure that you would accept my next best approach.  From what I
know of the extremely high technical competence of the other g++
developers, including the original author of std::string, I
rather thought that they would, too.  I'll admit that the
"hypothetical" bit surprised me.

The fact that I am not playing according to the official rules
is another issue -- I know that, too, but I feel 1) that the
official rules aren't really the best with regards to usability,
and above all, 2) the way they are formulated is somewhat
"ingenious".  Point 1 is, of course, personal opinion, but the
fact that some experts are also led astray by the formulation is
IMHO worth considering as a problem in itself.

|> This is not because you're threatening to woersen g++'s reputation
|> or disregard it in production use -- if it were that, I would not
|> worry ;-).

That's because you know that the competition is Sun CC (which is
no competition at all), and that I don't get to choose the
compiler anyway:-).

Seriously, however, I think you understand why I might feel
obligated in certain contexts to mention the fact that g++ does
have problems with regards to threading.  Not problems like pre
3.0 had, of course, but the fact is that it doesn't always
conform to the local conventions.  Sometimes, for some very good
reasons, but differences have to be doubly documented, because
people don't expect them.

|> This is because no matter what we might say in our FAQ,
|> if the behaviour is odd enough or singular enough, it entails Fear,
|> Uncertainty and Doubt.  That is not what we want.

I think that's the key.  People should feel at ease with the
tool.  Globally, I like g++ -- it's become my preferred compiler
for most things.  Which just makes me more upset about any
weaknesses.  (Like the absence of export, for example:-).)

--
James Kanze

"This message, including any attachments may contain confidential and
privileged material; it is intended only for the person to whom it is
addressed. Its contents do not constitute a commitment by Credit Agricole
Cheuvreux except where provided for in a written agreement. Credit Agricole
Cheuvreux assumes no liability or responsibility for the consequences
arising out of a delay and/or loss in transit of this message, or for
corruption or other error(s) arising in its transmission and for any misuse
or fraudulent use which may be made thereof. If you are not the intended
recipient, please contact us and abstain from any disclosure, use or
dissemination. To the extent that this message contains research
information and/or recommendations, these are provided on the same basis as
Credit Agricole Cheuvreux's published research and the recipient must have
regard to all disclosures and disclaimers contained therein."






-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334

Reply via email to