🚀 go-pugleaf

Nathan Myers <http://www.cantrip.org/> wrote:
> 
> David Brownell wrote:
> >
> > Tom Payne wrote:
> > > Is there agreement on what is meant by the term "thread safe."  (I have
> > > seen definitions that seemed quite inadequate.)
> >
> > IMHO "Thread-safe" is a misleading goal.  You actually want an API that's
> > natural to use in a threaded environment ... in some cases, that means an
> > API that's OK to use from concurrent threads (e.g. add to containers),
> > but in other cases it's reasonable to have objects that are only usable
> > from a single thread (e.g. iterators).
> 
> In this sense, STL (and the whole std library) is already MT-safe.

I disagree ... "the whole std library" isn't "natural" to use,
minimally since iostreams don't provide the analogue of stdio
flockfile().  Programmers have to invent their own synchronization; you
don't have the guarantees C programmers have.  Namely, that code like
this will not interleave output from two threads except between chunks
of fully formatted data:

	flockfile (stdout);
	/* many calls to emit a chunk of formatted data ... */
	putc, putc, putc, printf, puts, putc, putc, printf, ...
	funlockfile (stdout);

Currently, the C++ library interfaces don't provide primitives to
synchronize use of the library objects by different threads.  It's
_very_ natural to expect the library to define such a convention.  If
the standard library doesn't include one, there will be many -- and the
different conventions won't interoperate, so new kinds of bugs will
have found a good home.

This issue applies to STL as well as to iostreams.  Containers are
often used by multiple threads, so would benefit from shared/exclusive
(read/write) locking being available with standardized templates.
There are interactions with iterators too:  most iterators will want a
stable "snapshot" view (as in single-threaded code) without preventing
other threads from using the container concurrently.


> Of course this depends on it being implemented properly, but there are
> no interfaces in the standard C++ library that cry out for "_r" versions,
> as were found in the C library.  This is not accidental.

I hope you're right about this, but keep in mind that defining
interfaces that don't use "global" state (and so don't need "_r"
versions) is only one part of the interface definition problem.
Providing synchronization support is another part of the problem, as is
resolving performance issues that can sometimes be created due to lock
contention.  And let's not forget nailing down any locking hierarchy
rules to be followed by subclassers!


> This is not to say that the STL containers can be shared between threads
> without some kind of synchronization.

With respect to STL one might make the same argument Booch made (as I
recall) when he first did his generic components in Ada:  policy
flexibility is needed.

Today's STL components require external synchronization, which is one
policy.  But that really doesn't help in common scenarios such as
threads sharing containers and the resources they hold.  From where I
sit, it's more useful to have those (often) tricky MT algorithms made
generic than to have the same thing done with simple linked list
algorithms.
-- 
David Brownell
http://www.netcom.com/~brownell
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]