Date: Thu, 18 Feb 1999 03:30:21 -0500 (EST)
From: Bob McWhirter <bob AT werken DOT com>
X-Sender: bob AT exeter DOT exeter DOT org
To: Alexandre Oliva <oliva AT dcc DOT unicamp DOT br>
cc: Paul Derbyshire <pderbysh AT usa DOT net>, djgpp AT delorie DOT com,
        egcs AT egcs DOT cygnus DOT com
Subject: Re: [Semi-OT] The C++ Standard Library
In-Reply-To: <or4sokyw27.fsf@araguaia.dcc.unicamp.br>
Message-ID: <Pine.LNX.3.96.990218032621.19691K-100000@exeter.exeter.org>
X-URL: www.werken.com
X-Buzzword: digital pipeWrench
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com

On 18 Feb 1999, Alexandre Oliva wrote:

> On Feb 18, 1999, Paul Derbyshire <pderbysh AT usa DOT net> wrote:
> 
> > Q: Are STL containers guaranteed to be thread safe?
> 
> No.  You must lock them externally.  However, it seems to me that the
> SGI STL, distributed with egcs, provides some threading support, but
> you'd have to check.

From what I recall, the -latest- SGI STL is Roughly Threadsafe.

You can have multiple threads safely reading a container, but
if you plan to write/update/munge a container, no-one else can
be reading it.

(there really is no way for them to lock some things internally,
ie:

	typedef map<string, string> SSMap;

	SSMap foo, bar;

	foo["a"] = bar["a"];

Each half  of the assignment would need to lock the container, 
but what you really need is a lock around the entire statement.

Strangely enough, it seems that on Solaris, the Alloc classes 
aren't threadsafe (or is it just my underlying malloc that's
bogus), and I -must- -D_PTHREADS in order for the STL to 
serialize access to allocations.

Elsewise, simple copy-constructoring a container will occasionally
segfault.

Note though, wrapping that Allocator with a lock gives less-than-stellar
performance.

Are there plans in 1.1.2 to include the most recent SGI STL?

-Bob