Solved. gcc did reorder some mutex related counter/bool assignments
which should be done right in order. They come in from an argument
pointer, so I did trust this order. Have set them to volatile, that
did fix the bug. Is this a new gcc feature or a gcc bug?
Joerg
Joerg Bergmann schrieb:
Sorry for hijacking threads. This is a _new_ mail.
uname -a:
Linux phenom.phy.tu-dresden.de 2.6.27.9-73.fc9.i686 #1 SMP Tue Dec 16
15:25:05 EST 2008 i686 athlon i386 GNU/Linux
Phenom 2750 2.4 GHz 125W, Gigabyte MA790X-DS4 mainboard,
4GB DDR2 ECC RAM
It's my own numerical pthread multithreaded application BGMN
(www.bgmn.de). I the past, prior to Phenom and Fedora 9, BGMN worked OK.
Fedora early in 2008, BGMN worked OK (I got a warning message early at
boot time about disabled quit'n'cool). Starting in Autumn, I observed
BGMN to stop accidentally. BGMN uses a master thread and 1...4 slave
threads. On 2...4 slave threads, slave threads communicate using
mutexes. With 1 slave thread, these mutexes leave unused. BGMN did never
stop when using only 1 slave thread. One time, I got accidentally an
error while freeing a mutex. As a workaround, I did set MAX_SPEED
and MIN_SPEED to 2400 in /etc/sysconfig/cpuspeed. That worked,
even with 4 threads the program seems to run properly.
Anyone similar observations?
Joerg
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
