Re: libstdc++/5347: implementation is not thread-safe on multi-processor machines

Re: libstdc++/5347: implementation is not thread-safe on multi-processor machines

[ljrittle]

Synopsis: implementation is not thread-safe on multi-processor machines

Responsible-Changed-From-To: unassigned->ljrittle
Responsible-Changed-By: ljrittle
Responsible-Changed-When: Tue Jan 15 17:36:08 2002
Responsible-Changed-Why:
    Mine.
State-Changed-From-To: open->closed
State-Changed-By: ljrittle
State-Changed-When: Tue Jan 15 17:36:08 2002
State-Changed-Why:
    Duplicate of libstdc++/5037 (which is closed since it is
    fixed on mainline for 3.1 and, if ever released, 3.0.4+).
    I have tested this case against a patched copy of gcc
    3.0.3 on an MP sparc and it works without crashing.
    I have attached the patch against gcc-3.0.3.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5347

libstdc++/5347: implementation is not thread-safe on multi-processor machines

[markus.breuer]

>Number:         5347
>Category:       libstdc++
>Synopsis:       implementation is not thread-safe on multi-processor machines
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jan 10 04:56:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     markus.breuer@materna.de
>Release:        up to current release
>Organization:
>Environment:
sun solaris 2.7/2.8 (multi-processor machine)
gcc 2.95.3 up to 3.0.x
>Description:
The libstdc++ implementation is not really thread-safe. 
Currently we allocate ostrstreams/ostrstreams with new and free them
immediatelly with delete. There's no access the the objects (except
new and delete), but the application sometimes crashes.

The main problem are static variables within streambuf (and perhaps other classes).
When instantiating an derived object (e.g. filestreambuf), this variables 
are accessed. On a single processor machine these accesses may be atomic (
depending on hardware), but an a real multi-processor environment they are not atomic.
When running our application on a single processor machine, there are no further 
problems, but on multi-processor there are unavoidable system crashes (core dumps).
>How-To-Repeat:
Compile and run the attached program on a (sun!?) multi-processor machine
>Fix:
To fix the problem the access to any global variable must be synchronized. Search
the libstdc++ for any static variable (streambuf/basic_string/etc) and use atomicity
to synchronize any access to it. Any access, read and write, must be synchronized.
The basic_string class uses atmicity to synchronize access to nulRep and Rep. But 
only the write access is synchronized. In a multi-processor environment the write access
of, for example an pointer, is not atomic. So its read-access must be guarded by
atomicity.
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="HMSTestApp.cpp"; name="HMSTestApp.cpp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="HMSTestApp.cpp"

Ly8gY21kOiBnKysgSE1TVGVzdEFwcC5jcHAgLWcgLXB0aHJlYWRzCgojaW5jbHVkZSA8c3RyaW5n
PgojaW5jbHVkZSA8ZnN0cmVhbT4KI2luY2x1ZGUgPGlvc3RyZWFtPgojaW5jbHVkZSA8c3Ryc3Ry
ZWFtPgojaW5jbHVkZSA8dW5pc3RkLmg+CgojaW5jbHVkZSA8cHRocmVhZC5oPgojaW5jbHVkZSA8
dGhyZWFkLmg+Cgpjb25zdCBpbnQgbWF4X3RocmVhZF9jb3VudCA9IDE2Owp2b2xhdGlsZSBpbnQg
cnVubmluZ1RocmVhZHMgPSBtYXhfdGhyZWFkX2NvdW50OwoKcHRocmVhZF90IHRpZFsgbWF4X3Ro
cmVhZF9jb3VudCBdOwoKdXNpbmcgbmFtZXNwYWNlIHN0ZDsKCnZvaWQqIHRocmVhZF9tYWluKCB2
b2lkICogKQp7CiAgIHN0ZDo6Y291dCA8PCAiRW50ZXJpbmcgdGhyZWFkICMiIDw8IHB0aHJlYWRf
c2VsZigpIDw8ICIuLi4iIDw8IHN0ZDo6ZW5kbDsKICAgCiAgIGludCBtYXggPTEwMDAwMDA7Cgog
ICB3aGlsZSggbWF4LS0gKQogICB7CiAgICAgIHRocl95aWVsZCgpOwogICAgICAKICAgICAgb3N0
cnN0cmVhbSAqcG9zOwogICAgICBvZnN0cmVhbSAqcG9zMTsKICAgICAgcG9zID0gbmV3IG9zdHJz
dHJlYW07ICAgICAgCiAgICAgIC8vIHNvbWV0aW1lcyBkZWxldGUgdGhyb3dzIGEgY29yZSBkdW1w
CiAgICAgIGRlbGV0ZSBwb3M7CiAgICAgIHBvczEgPSBuZXcgb2ZzdHJlYW07CiAgICAgIC8vIHNv
bWV0aW1lcyBkZWxldGUgdGhyb3dzIGEgY29yZSBkdW1wCiAgICAgIGRlbGV0ZSBwb3MxOwogICAg
ICAKICAgICAgaWYgKG1heCUxMDAgPT0gMCApCiAgICAgIGNvdXQgPDwgIiMiIDw8IHB0aHJlYWRf
c2VsZigpIDw8IGVuZGw7CiAgIH0KICAgcnVubmluZ1RocmVhZHMtLTsKICAgc3RkOjpjb3V0IDw8
ICJMZWF2aW5nIHRocmVhZCAjIiA8PCBwdGhyZWFkX3NlbGYoKSA8PCAiLi4uIiA8PCBzdGQ6OmVu
ZGw7CiAgIAogICByZXR1cm4gMDsKfQoKCmludCBtYWluKCkKewogICBpbnQgY3RyOwogICAKICAg
c3RkOjpjb3V0IDw8ICJTdGFydHVwIC4uLiIgPDwgc3RkOjplbmRsOwogICAKICAgZm9yKCBjdHI9
MDsgY3RyIDwgbWF4X3RocmVhZF9jb3VudDsgY3RyKysgKQogICB7CiAgICAgIHB0aHJlYWRfdCBw
dCA9IHB0aHJlYWRfY3JlYXRlKCAmdGlkW2N0cl0sIE5VTEwsIHRocmVhZF9tYWluLCAwICk7CiAg
ICAgIHN0ZDo6Y291dCA8PCAidGhyZWFkICIgPDwgY3RyKzEgPDwgIiBzdGFydGVkIC4uLiIgPDwg
c3RkOjplbmRsOwogICB9CiAgIHdoaWxlICggcnVubmluZ1RocmVhZHMgKQogICAgICBzbGVlcCgg
MSApOyAgIAogICBzdGQ6OmNvdXQgPDwgIlNodXRkb3duIC4uLiIgPDwgc3RkOjplbmRsOyAgICAg
IAogICAKICAgcmV0dXJuIDA7Cn0KCg==