This is the mail archive of the
mailing list for the libstdc++ project.
Re: Thread safety clarification
[Get raw message]
- To: rittle at labs dot mot dot com
- Subject: Re: Thread safety clarification
- From: David Waite <mass at akuma dot org>
- Date: Tue, 13 Nov 2001 09:11:06 -0700
- Cc: libstdc++ at gcc dot gnu dot org
- References: <200111130033.fAD0XCM52224@latour.rsch.comm.mot.com> <200111130617.fAD6HWq19046@latour.rsch.comm.mot.com>
Loren James Rittle wrote:
>Benjamin covered the rest of your e-mail (in terms of asking for more
yep - always helpful to know where to start :-)
>>According to the FAQ in CVS, you cannot assume that two separate threads
>>can simultaneously read from a STL container class at once; however,
>>according to the containers howto (23_containers/howto.html) and the SGI
>>multithreading document (http://www.sgi.com/tech/stl/thread_safety.html)
>>both say this is acceptable behavior. Which goes - is the lack of
>>thread-safety on container read an issue with libstdc++, and if so, what
>>is the actual issue (as perhaps I can work on it)
>For STL components, IMHO 23_containers/howto.html and SGI documents
>(excluding any configuration information given there) override
>anything you may have found elsewhere.
>In particular, the concrete example in faq/index.html (5.6 Is
>libstdc++-v3 thread-safe?) explicitly involves mutating a shared
>object and is not really the same thing you ask about. Since we are
>talking about the entire library, we must be conservative in the
>explanation of the design rules. However, I do agree that the
>follow-up text needs some additional clarification to avoid being
> [...] This requirement includes both read and write access to
> objects; do not assume that two threads may read a shared
> standard container at the same time.
>How about the following text?
> [...] 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.
>This change works by generalizing the word choice to ``standard
>library object'' from ``standard container'' while making it clear
>that there are exceptions. When one does more detailed study in the
>23_containers/howto.html, one will see that readonly access is
>well-defined on the standard containers in some conditions (i.e. a
>documented exception to the general rule).
Much better :-)
Are there examples of objects which cannot be accessed from multiple
threads simultaneously? For example, can I have multiple threads reading
from a globally-defined, constant string?