------- Additional Comments From rittle at latour dot waar dot labs dot mot dot
com 2005-05-03 19:08 -------
Subject: Re: Lack of Posix compliant thread safety in
std::basic_string
>|> 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.
Of course, we want quality (and we want performance) which is why we
insist upon non-hypothetical bug reports (either way, I've already
explained what is wrong with your posted code w.r.t. the cited FAQ
entry) and why we insist that library users must write correct locking
sequences outside the context of the library. As you well know, there
is nothing in POSIX which dictates that a library internalize the
locking vs. implying that the user code must hold a mutex lock.
You observe that we should make string<> act exactly like char[] from
the user's perspective. Neither the cited FAQ (which I just reviewed
in detail, esp. the full text of section 5.6) nor POSIX modified as
you'd wish implies that at all. char[] is a raw chunk of memory. In
the cited FAQ, we explain that any method call on any shared object
must be mutex-protected unless we specially document the method or the
entire class. We are stating that we do nothing inside the library
which would make it impossible for a user to write threaded
application with our library. As I've already observed to you,
string<> may or may not be specially documented. If it is, then you
need to cite that documentation in your bug report, not the general
FAQ section 5.6. This is basically my point. The view expressed in
the FAQ section 5.6 is entirely consistent with the POSIX view (as
conveyed to me by Butenhof's book). POSIX doesn't care what portions
of the C or C++ application have to apply mutex locks to ensure it happens.
The prime issue is visibility of the object. We take responsibility
for locking access to internally hidden shared objects whenever the
holding reference was not itself visibility shared in the application
code. When the holding reference was visibility shared in the
application code, then the user is responsible for locking access. In
your posted code, the user has direct visibility to the shared object
thus he must hold a lock under our general model (also the SGI STL
general model). If the shared object was invisible to the user
(i.e. a shared cache not implied by the standard which is indirectly
accessed by two independently declared library objects) and we failed
to hold a mutex internal to the library, then I would be more
interested in your report...
Our general recommendations precisely covers this case. I will go
farther: Any locking model under C++ which fails to account for object
model visibility will likely perform like a real dog. Bow Wow.
BTW, I noticed that you had no response to my point that you are using
an incorrect locking idiom in your posted code w.r.t. our general FAQ.
If you would like to object that your posted code fails w.r.t. another
section of the FAQ which offers special guarantees, then I will likely
not complain if you close this PR and open a new one.
> Well, there's certainly some confusion, because Posix says one
> thing, and your documentation says another.
Huh? POSIX dictates when code must do or not do something to ensure
that the threading model is sound. We dictate when user code must do
something in line with the POSIX model. We tell the user precisely
when they must account for locks when working with library objects.
Is it complex (in C++)? Yes.
> When you say "treat library objects like any other shared
> resources', you are contradicting yourself for a system using the
> Posix model.
There is no contradiction. We made it clear what you have to do when
you use the library to ensure that your entire program is thread-safe.
If you insist on cutting a corner, what can we do?
If you think other words would be better in our FAQ, then I will take
no offense as the last author of that section if you propose a change.
> [...] 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.
Humm... If you would like to fix the library to match your
expectations instead of crafting application-level code as we (and
SGI) suggest, then please be our guest. Your patch will only be
accepted if you don't kill library performance.
> 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.
I think our guarantee is now well-qualified and surely better than
what was stated pre-gcc 3.0. I think you actually don't like our
qualification.
I think I can safely assure you that if you construct your C++ code
precisely as we document in section 5.6, you will never violate a
requirement of POSIX nor cause the library itself internally to
violate a requirement of POSIX. If you cut a corner, what can we do?
Regards,
Loren
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
