|
From: Nicholas N. <nj...@ca...> - 2004-04-10 01:31:44
|
Hi, Does a terminating pthread unlock all held mutexes? Thanks. N |
|
From: Christoph B. <bar...@gm...> - 2004-04-10 08:20:55
|
Am Samstag, 10. April 2004 03:31 schrieb Nicholas Nethercote: > Hi, > > Does a terminating pthread unlock all held mutexes? > No, http://www.opengroup.org/onlinepubs/007904975/functions/pthread_exit.html "Thread termination does not release any application visible process resources, including, but not limited to, mutexes and file descriptors, nor does it perform any process-level cleanup actions, including, but not limited to, calling any atexit() routines that may exist." Christoph Bartoschek |
|
From: Nicholas N. <nj...@ca...> - 2004-04-10 11:43:15
|
On Sat, 10 Apr 2004, Christoph Bartoschek wrote: > > Does a terminating pthread unlock all held mutexes? > No, > > http://www.opengroup.org/onlinepubs/007904975/functions/pthread_exit.html > > "Thread termination does not release any application visible process > resources, including, but not limited to, mutexes and file descriptors, nor > does it perform any process-level cleanup actions, including, but not > limited to, calling any atexit() routines that may exist." Interesting; this raises two issues. 1. Are there any legitimate reasons for a thread to not unlock a mutex before it terminates? If not, then it would be nice if Valgrind warned about such behaviour, no? Since no other thread should unlock the mutex, it will stay locked forever, AIUI. 2. Because Valgrind's libpthread recycles ThreadIds, it's possible to lock a mutex with one thread, then it dies, then another thread is spawned and it unlocks it; but the badness here is not detected because both threads have the same ThreadId. Perhaps Valgrind should not recycle ThreadIds? N |