Date: Fri, 10 Nov 2000 18:25:08 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jar@integratus.com (Jack Rusher) Cc: james@targetnet.com (James FitzGibbon), hackers@FreeBSD.ORG Subject: Re: Repeatable STL core with -pthread Message-ID: <200011101825.LAA23555@usr08.primenet.com> In-Reply-To: <3A0B2E87.3B49887B@integratus.com> from "Jack Rusher" at Nov 09, 2000 03:08:55 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > The program will core after about 10 seconds, every time.
> > It would appear that there is an issue with some low-level allocator in the
> > STL as shipped in 4.x.
>
> Dude. The STL implementation that ships with g++ isn't thread safe.
> In fact, if you read the STL portion of the C++ specification, you will
> notice that threads are not mentioned at all. The only guarantees made
> by the STL are that operations will complete within certain performance
> guidelines.
>
> As a safety tip, the string implementation in the g++ implementation
> isn't thread safe either. It uses a shared buffer scheme ("char*
> string->rep") to reduce memory consumption & improve performance. This
> is in opposition to "deep copy" style libraries, like the SGI STL, that
> work in threaded environments.
>
> Because of the way the C++ standard is written, commercial STL
> implementations, such as the Rogue Wave library that comes with the Sun
> C++ compiler, suffer from the same threading problems.
Use the STL that is used by the Cyrus ACAP server, which is the
one from the Moscow Center for Supercomputing Activities.
There is an issue in GNU C++ with an assumption by the ACAP
code about dynamic virtual base class construction order at
load time, but it can be handled by ensureing that the link
order ensures that classes are linked lowest level to highest
level, in reverse dependency order.
The Moscow STL also has a large number of bug fixes; Jeremy
Allison (of Samba) and myself spent a fair amount of time
adding in support for Draft 4 pthreads, and making it work
on FreeBSD at the time (which included patches to FreeBSD of
the time to bring it into compliance with Draft 4). Without
these, you will probably have a hard time making the STL code
work on both modern FreeBSD, and on, say, IRIX, which is still
Draft 4. But if this is not a portability issue for you, I
would suggest using that STL instead.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011101825.LAA23555>