🚀 go-pugleaf

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).

Consider for example POSIX.1c "putc_unlocked()" ... not thread-safe by itself,
but very usable for high performance character I/O since it's always used in
conjunction with "flockfile()" (in non-erroneous programs).

(See my writeup at http://www.netcom.com/~brownell/pthreads++.html for some
discussion of the "policy" that a useful MT-safe version of the standard
C++ library ought to follow.  It also covers a bunch of other C++/MT issues
that come up in the POSIX.1c/C++ environment.  Comments, please!)


> : Eventually, the vendors ought to agree on one way to do threaded C++,
> : but we're not there yet!  I don't know how much commonality there is
> : between different MT/C++ environments but I suspect it's not lots.
> 
> The standards process is the appropriate forum for such vendor
> agreement.  Unfortunately, the standards bodies have failed to provide
> the necessary leadership in the areas involving concurrency and
> asynchrony.  Perhaps, these bodies simply have other fish to fry --
> getting the current standard completed is an monumental task.

Well, POSIX.1c happened; it's the ANSI/ISO C++ team that's said such
issues are "out of scope" for now.  I don't think it's realistic to
expect POSIX to produce a C++ binding at this time, given some of the
issues raised in my writeup above.  Nor do I think vendors should be
gratuitously diverging, even lacking a formal standards framework.

>	  I
> detect, however, some reluctance to address matters of concurrency and
> asynchrony for fear of:

Hmmm, "concurrency" and "asynchrony" are broader issues than threading.
Many people use threading to _avoid_ asynchrony, for example.

>   ...
> 
> Although each of these fears has some arguments for it, the portable
> implementations of Modula and Ada offer evidence that the difficulties
> are surmountable.  Meanwhile, a C++ program (with defined behavior)
> cannot deal efficiently with some of the simplest asynchrony, e.g., a
> hardware-detected exception cannot generate a program exception,
> unless the program explicitly polls for it, thus, requiring
> unacceptable overhead both in running time and programming effort.

Some of us don't think that it's necessarily a good thing to complicate
C++ exception processing further -- it's a synchronous mechanism now.
I'd hope that the current mechanism for asynchrony (signals) would just
be fixed to address your issues!
-- 
David Brownell
http://www.netcom.com/~brownell
---
[ 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 
]