🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.programming.threads
Article #14

Re: Is STL MT-Safe?

#14
From: Tom Payne
Date: Wed, 17 Apr 1996 08:29
57 lines
3605 bytes
David Brownell (brownell@ix.netcom.com) wrote:
: > I believe Modena or one of the other commercial STL library vendors has
: > added a certain degree of thread-awareness to their implementation. I
: > might be wrong, but I have a feeling that it is still not entirely
: > thread-safe.
: 
: 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.)

: 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.  I
detect, however, some reluctance to address matters of concurrency and
asynchrony for fear of:

  *  limiting the range of architectures on which the langauge
     in efficiently implmentable,

  *  introducing incomapatibilities with vendor-established 
     extensions,

  *  commitment to one or another particular model for 
     concurrent programming.

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.

There have been suggestions that such matters should be addressed by
the C Standards Committees and possibly incorporated by reference into
the C++ Standard by reference.  While it is important to maintain as
much commonality as possible, there are considerations that are unique
to C++, e.g., interaction with exceptions.

Tom Payne (thp@cs.ucr.edu)
---
[ 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                             ]
Technical Details
Message-ID: <4l12rf$q11@galaxy.ucr.edu>
Path: arc1-ca.pugleaf.net!in2.uu.net!bounce-back
References: <4kmjvj$89t@usc.edu> <4kspmb$9tb@ubszh.fh.zh.ubs.com> <3173E95E.5AC@ix.netcom.com>

Show Full Headers
Complete Article Headers
From: thp@cs.ucr.edu (Tom Payne)
Message-ID: <4l12rf$q11@galaxy.ucr.edu>
X-Original-Date: 16 Apr 1996 21:18:39 GMT
Path: arc1-ca.pugleaf.net!in2.uu.net!bounce-back
Date: 17 Apr 96 08:29:22 GMT
Approved: fjh@cs.mu.oz.au
Newsgroups: comp.programming.threads,comp.std.c++
Subject: Re: Is STL MT-Safe?
Followup-To: comp.programming.threads,comp.std.c++
Organization: University of California, Riverside
References: <4kmjvj$89t@usc.edu> <4kspmb$9tb@ubszh.fh.zh.ubs.com> <3173E95E.5AC@ix.netcom.com>
X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
X-Auth: PGPMoose V1.1 PGP comp.std.c++
 iQBFAgUBMXSr6+EDnX0m9pzZAQETPgF+OTycFY/pXpmPGcVmYwT3xhJWTsLyeKXz
 ThlXJYwEvcV+fRrSdPGgJXKxb89ldM6A
 =MeI0