Re: Repeatable STL core with -pthread

2000-11-10 Thread Terry Lambert

  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
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Repeatable STL core with -pthread

2000-11-09 Thread James FitzGibbon

We're having a problem with threaded programs that use the STL.  Given the
following program:

--START--
#include string
#include pthread.h

typedef mapint, int mymap_t;

#ifdef GLOBLOCK
pthread_mutex_t glob_mut;
#endif

void *run(void *) {

while (1) {
string f("");
#ifdef GLOBLOCK
pthread_mutex_lock(glob_mut);
#endif
f += "adsasd";
f += "adsasd";
f += "adsasd";
#ifdef GLOBLOCK
pthread_mutex_unlock(glob_mut);
#endif
}

}

int main () {

#define FOO 50
pthread_t thread[FOO];

for(int x =0;xFOO;x++) {
pthread_create(thread[x], NULL, run, NULL);
}

for(int x =0;xFOO;x++) {
pthread_join(thread[x], NULL);
}   

exit(0);
}
---END---

When compiled like so:

c++ -g -pthread -o stl_core.cc stl_core.cc

The program will core after about 10 seconds, every time.  When compiled
with -DGLOBLOCK, it runs without fail.  I have tried this using gcc 2.95.1,
2.95.2, egcs-20001002 and 20001106 without success.  I have also tried using
the linuxthreads port, and with Matt Dillon's lowmem patch (can't remember
the URL offhand) and with Daniel Eischen's libc_r patches against -stable.

Under RedHat Linux 7.0 (kernel 2.2.16) using gcc 2.96 (development version),
the program works fine.

It would appear that there is an issue with some low-level allocator in the
STL as shipped in 4.x.  Because everything in the STL is build around said
allocator, this fails for almost anything that uses STL (the original test
program I used allocated a map rather than a string).

I'd appreciate any ideas this brings forth in people.

Thanks.

-- 
j.

James FitzGibbon   [EMAIL PROTECTED]
Targetnet.com Inc.  Voice/Fax +1 416 306-0466/0452


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Repeatable STL core with -pthread

2000-11-09 Thread Jack Rusher

James FitzGibbon wrote:
 
 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.

-- 
Jack Rusher, Senior Engineer | mailto:[EMAIL PROTECTED]
Integratus, Inc. | http://www.integratus.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message