------- Additional Comments From jkanze at cheuvreux dot com 2005-05-03 08:56 ------- Subject: Re: Lack of Posix compliant thread safety in std::basic_string
|> >I am sending this to the g++ bug list on the recommendation of |> >Gabriel Dos Reis. From what little I've read in the g++ |> >documentation, I'm not convinced that the authors of the g++ |> >library intend for it to be supported, although Posix would seem |> >to require it. |> Firstly, POSIX says nothing about C++ thus my confusion starts here. The statement I quoted from the Posix standard is language neutral. A priori, it applies to all languages. |> Secondly, it is clear that your bug report is hypothetical. The |> library maintainers do not typically deal in hypotheticals. I guess it is really a question of whether you want quality or not. In general, all code is supposed incorrect until proven otherwise -- in the case of threading issues, this is particularly important, because of the random factors involved. In this particular case, there is only a very, very small window of time in which the error can occur. I could add a lot of extra code, which would only obfuscate the real problem, but would increase the chances that the error occurs. I could probably, experimentally, add just the right amount so that the error occurred more or less regularly (say one execution in ten) on my machine. Unless your machine had exactly the same configuration (processor, clock speed, background processes, etc.), the error would probably not trigger there. |> >For the record, the statement in Posix is: "Applications shall |> >ensure that access to any memory location by more than one |> >thread of control (threads or processes) is restricted such that |> >no thread of control can read or modify a memory location while |> >another thread of control may be modifying it." The obvious |> >extension to C++ is that of replacing "memory location" with |> >"object"; at the very least, of course, one can only require |> >something of "memory locations" which the user sees, directly or |> >indirectly. |> OK. |> >The statement in the libstdc++-v3 FAQ (question |> >5.6) 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." |> OK, I seem to recall editing that statement at one point... |> >A considerably weaker guarantee than what one |> >normally expects under Posix. (Note that the clause "like any |> >other shared resource" is simply false for those of us used to |> >the Posix model. If I replace std::string with char[] in my |> >code below, the behavior is perfectly defined under Posix.) |> No, confusion. We are guaranteeing that if you lock the visible |> accesses to global or otherwise shared objects, that no POSIX |> threading rule will be violated within our own library code. Well, there's certainly some confusion, because Posix says one thing, and your documentation says another. When you say "treat library objects like any other shared resources', you are contradicting yourself for a system using the Posix model. In the case of string, of course, the obvious "other' system resource to compare it with is char[]. If you replace std::string with char[], in my example program, the code is well defined and guaranteed to work under Posix. |> We are |> saying that we guarantee that any internal shared objects (which may |> not be visible to the user, thus not lockable by the user) will be |> correctly handled per POSIX threading rules. I know what you are guaranteeing (in the statement above). It's because of this statement (or a similar one elsewhere in the documentation) that I hadn't sent in a bug report, but that I did take the bother of warning people in various news groups that in g++, std::string did not behave as one would normally expect. You can use it, but you have to take additional precautions that Posix says shouldn't be necessary, and that experienced Posix users don't expect to need. An implementation, of course, is free to decide what it wants to guarantee, and what it doesn't. If it is decided, however, that the Posix guarantees do not extend to the library, then it is important to document this fact; i.e. to indicate somewhere that it cannot be missed that configuring the compiler to support pthreads does NOT mean what it seems to mean. -- 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
