From owner-freebsd-hackers Fri Nov 10 14:13:43 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 5FB4237B4C5 for ; Fri, 10 Nov 2000 14:13:41 -0800 (PST) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id PAA07207; Fri, 10 Nov 2000 15:12:42 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpdAAAmHaORp; Fri Nov 10 11:24:22 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id LAA23555; Fri, 10 Nov 2000 11:25:08 -0700 (MST) From: Terry Lambert Message-Id: <200011101825.LAA23555@usr08.primenet.com> Subject: Re: Repeatable STL core with -pthread To: jar@integratus.com (Jack Rusher) Date: Fri, 10 Nov 2000 18:25:08 +0000 (GMT) Cc: james@targetnet.com (James FitzGibbon), hackers@FreeBSD.ORG In-Reply-To: <3A0B2E87.3B49887B@integratus.com> from "Jack Rusher" at Nov 09, 2000 03:08:55 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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