[libstdc++] Notes on threading and I/O

[Loren James Rittle]

In article < 20011009182532.A23937@disaster.jaj.com > you write:

I have no complaint with any other update. ;-)

> [...] libstdc++-v3/docs/html/faq/index.html [...]
>    <h2><a name="5_6">5.6 Is libstdc++-v3 thread-safe?</a></h2>
>-      <p>Quick answer:  no, as of 2.92 (eleventh snapshot), the
>-         library is not appropriate for multithreaded access.  The
>-         string class is MT-safe.
>+      <p>Quick answer:  no, as of 3.0, most of the library is not
>+         safe for multithreaded access.  The string class is MT-safe.
>       </p>
>       <p>This is assuming that your idea of "multithreaded"
>          is the same as ours...  The general question of multithreading
[...]

Hi Phil,

To say that the answer is ``no'' conflicts with information given
elsewhere.  It is better, IMHO, to state under which conditions the
library is thread-safe than to ``just say no'':

<p>When the system's libc is itself thread-safe, libstdc++-v3 strives
to be thread-safe as long as the user-code guards against concurrent
active method calls which may change a particular library object's
state.  However, the library is not yet formally documented to
describe which methods may change object state.  As of libstdc++-v3
released with gcc 3.0, beware that there are cases where shared nested
or global objects are affected or used without any internal locking.
</p>
<p>In some cases, a stronger thread-safe guarantee is made.  The
string class is guaranteed to be thread-safe without user-code guards.
The IO classes are guaranteed to be thread-safe with user-code guards
whenever the same user-visible object may be accessed by multiple
threads.  The container classes are guaranteed to be thread-safe with
user-code guards whenever the same container may be accessed by
multiple threads.  All accesses to hidden objects (e.g. the global
allocator objects) are internally guarded.
</p>
<p>See chapters 17, 23 and 27 for more information.
</p>

- End of FAQ answer -

Even with the stated restriction, we still meet the definition of
thread-safe as most people understand it (and my wording avoids
referring to "assuming your idea is the same as ours" by explicitly
stating the restriction).  Being thread-safe means being able to
invoke some sets of code paths, or a particular code path multiple
times, concurrently on different data.  Having to hold various locks
when various objects, which are known to more than one thread, are
passed to various functions does not make a code base fundamentally
non-thread-safe.

In the best of all world, we would clearly publish which method calls
may change state and thus might require an application-level locking
strategy.  However, I don't see that happening.

No offense, but we should lose all references to "Received Wisdom"
since we sound more like a cult manual than a technical FAQ. ;-)

Regards,
Loren