🚀 go-pugleaf

David Brownell wrote:
> 
> Tom Payne wrote:
> >
> > David Brownell (brownell@ix.netcom.com) wrote:
> > :
> > : Someone else mentioned Rogue Wave.  Does anyone have URLS or something
> > : through which the different "MT-enhanced" APIs could be compared?  I've
> > : been organizing a collection of MT/C++ issues; one of the gaps is where
> > : the standard C++ library interfaces need to be "MT-safed" according to
> > : some useful and consistent policy.
> >
> > 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.
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.

This is not to say that the STL containers can be shared between threads
without some kind of synchronization.  Rather, it means that on a good
implementation, two copies of a string which happen to share representation
can be used by two threads, safely.  In other words, what is shared invisibly
is handled; what you can see is your responsibility.

Nathan Myers
ncm@cantrip.org  http://www.cantrip.org/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]