Hi, meanwhile I've digged through John Williams' platform stuff concerning the pthreadlib and it seems I've found the bug and also can give you a bugfix patch for this problem. I found out that my seen hang of pthread_mutex_unlock() was reasoned in a missing MEMORY_BARRIER() in the __compare_and_swap_with_release_semantics() call in __pthread_alt_unlock() which is in spinlock.c line 558. That leads to an infinite loop there in __pthread_alt_unlock(). I checked how __compare_and_swap_with_release_semantics() is implemented in the other architectures and they all do that MEMORY_BARRIER() in there. Now with my patch the microblaze does it as well and yippie it works now! :-) Both threads do blinking since hours here now. Also ps looks much better now. Not such strange 99% on several processes, although this maybe has nothing to do with the patch (?). Well, anyway please apply my attached patch. Cheers, F@lk > -----Original Message----- > From: owner-microblaze-uclinux@itee.uq.edu.au > [mailto:owner-microblaze-uclinux@itee.uq.edu.au]On Behalf Of > Brettschneider Falk > Sent: Friday, July 15, 2005 10:40 AM > To: microblaze-uclinux@itee.uq.edu.au > Subject: [microblaze-uclinux] pthread_mutex_[un]lock - I have a bad > feeling about this > > > Hi, > > Looking at > http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/archive > /2004/08/msg00 > 084.html I'd like to know if the problems have been fixed in > the meanwhile. > Have things been fixed in the pthread lib since that mail? > > Background: I have two threads just looping infinitely and > inverting an LED > state every 1 second, it means I see 2 LEDs blinking. Both threads > constantly must check the time by calling gettimeofday() to > find out the > switch-time. Since I read that function is not thread-safe I > secure the call > to it with a mutex. > Now the effect is after 3 to 15 seconds one of the threads has locked > forever, obviously on that mutex. It's undeterminated which > thread will > block, the other thread keeps on blinking. > > Here's the 'ps' and logfile output of my application: > > /usr> /bin/XXXXYYYY & > [56] > /usr> ps > PID PORT STAT SIZE SHARED %CPU COMMAND > 1 S 85K 0K 99.9 /sbin/init > 2 S 0K 0K 0.0 keventd > 3 S 0K 0K 99.9 ksoftirqd_CPU0 > 4 S 0K 0K 0.0 kswapd > 5 S 0K 0K 0.0 bdflush > 6 S 0K 0K 99.9 kupdated > 7 S 0K 0K 99.9 mtdblockd > 15 S0 R 140K 0K 0.1 /bin/sh > 56 S0 S 3699K 0K 10.7 /bin/XXXXYYYY > 57 S0 S 3699K 0K 0.0 /bin/XXXXYYYY > 58 S0 S 3699K 0K 18.3 /bin/XXXXYYYY > 59 S0 R 3699K 0K 85.2 /bin/XXXXYYYY > /usr>cat vs.log > y m d h m s ms > 0000/00/00 01:28:42:741: calling run_io() > 0000/00/00 01:28:42:749: calling run_service() > 0000/00/00 01:28:42:769: ---> IDLE > 0000/00/00 01:29:04:781: io: service thread not running! last state=1 > > > It's also not clear to me why the sleeping thread (58) still > has 18.3% CPU > load. > The crucial part of my test code is attached to this mail. > The files in uClibc/libpthread/linuxthreads/sysdeps/microblaze have a > modification time 24/01/2005. > > > > Mit freundlichen Grüßen / Best regards > > Falk Brettschneider > ___________________________________ > > Dipl.-Inform. Falk Brettschneider > Softwareentwickler / Software Developer > Baumer Optronic GmbH > http://www.baumeroptronic.de > > >
Attachment:
patchforhangof__pthread_mutex_unlock.diff
Description: Binary data