|
[Valgrind-users] pthread_cond_wait/timedwait: mutex is unlocked or is locked but
not owned by thread
From: Alberto A. <al...@gg...> - 2004-04-24 21:53:58
|
Environment: valgrind 2.1.1 running on Fedora 1 I'm not quite sure what this error means. Any ideas? ==12752== pthread_cond_wait/timedwait: mutex is unlocked or is locked but not owned by thread ==12752== at 0x3C048C91: pthread_cond_wait (vg_libpthread.c:1314) ==12752== by 0x3C029F9B: ggsysmsgsrvwrkthrd_start (ggsysmsgsrvwrkthrd.c:117) ==12752== by 0x3C029BBC: thrd_function (ggsysmsgsrvthrd.c:522) ==12752== by 0x3C047DA1: thread_wrapper (vg_libpthread.c:837) Thanks, Alberto -- Alberto Alonso Global Gate Systems LLC. (512) 260-2523 http://www.ggsys.net Hardware, consulting, collocation, monitoring and remote backups |
|
[Valgrind-users] pthread_cond_wait/timedwait: mutex is unlocked or is locked but
not owned by thread
From: Alberto A. <al...@gg...> - 2004-04-24 23:22:59
|
Environment: valgrind 2.1.1 running on Fedora 1 I'm not quite sure what this error means. Any ideas? ==12752== pthread_cond_wait/timedwait: mutex is unlocked or is locked but not owned by thread ==12752== at 0x3C048C91: pthread_cond_wait (vg_libpthread.c:1314) ==12752== by 0x3C029F9B: ggsysmsgsrvwrkthrd_start (ggsysmsgsrvwrkthrd.c:117) ==12752== by 0x3C029BBC: thrd_function (ggsysmsgsrvthrd.c:522) ==12752== by 0x3C047DA1: thread_wrapper (vg_libpthread.c:837) Thanks, Alberto -- Alberto Alonso Global Gate Systems LLC. (512) 260-2523 http://www.ggsys.net Hardware, consulting, collocation, monitoring and remote backups |
|
From: Nicholas N. <nj...@ca...> - 2004-04-25 19:12:15
|
On Sat, 24 Apr 2004, Alberto Alonso wrote:
> I'm not quite sure what this error means. Any ideas?
>
> ==12752== pthread_cond_wait/timedwait: mutex is unlocked or is locked
> but not owned by thread
> ==12752== at 0x3C048C91: pthread_cond_wait (vg_libpthread.c:1314)
> ==12752== by 0x3C029F9B: ggsysmsgsrvwrkthrd_start
> (ggsysmsgsrvwrkthrd.c:117)
> ==12752== by 0x3C029BBC: thrd_function (ggsysmsgsrvthrd.c:522)
> ==12752== by 0x3C047DA1: thread_wrapper (vg_libpthread.c:837)
Perhaps it would be clearer if it said:
"mutex is unlocked or is locked by another thread"
?
When a thread calls pthread_cond_wait(), it should have a lock on the
passed mutex. From the man page:
pthread_cond_wait atomically unlocks the mutex (as per
pthread_unlock_mutex) and waits for the condition variable cond to be
signaled. The thread execution is suspended and does not consume any
CPU time until the condition variable is signaled. The mutex must be
locked by the calling thread on entrance to pthread_cond_wait. Before
returning to the calling thread, pthread_cond_wait re-acquires mutex
(as per pthread_lock_mutex).
----
In this case, Valgrind's pthread_cond_wait return EINVAL... is this right?
The man page says:
pthread_cond_init, pthread_cond_signal, pthread_cond_broadcast, and
pthread_cond_wait never return an error code.
N
|
|
From: Henrik N. <hn...@ma...> - 2004-04-25 21:25:11
|
On Sun, 25 Apr 2004, Nicholas Nethercote wrote: > In this case, Valgrind's pthread_cond_wait return EINVAL... is this right? EPERM is probably more appropriate. And SUSv3 seems to agree with me here.. (see below) > The man page says: > > pthread_cond_init, pthread_cond_signal, pthread_cond_broadcast, and > pthread_cond_wait never return an error code. Which is a little odd as they also say they operate on the mutex as per the mutex unlock/lock operations wich may return errors.. SUSv3 (IEEE Std 1003.1-2001) says something more sensible: The pthread_cond_timedwait() function shall fail if: [ETIMEDOUT] The time specified by abstime to pthread_cond_timedwait() has passed. The pthread_cond_timedwait() and pthread_cond_wait() functions may fail if: [EINVAL] The value specified by cond, mutex, or abstime is invalid. [EINVAL] Different mutexes were supplied for concurrent pthread_cond_timedwait() or pthread_cond_wait() operations on the same condition variable. [EPERM] The mutex was not owned by the current thread at the time of the call. These functions shall not return an error code of [EINTR]. Regards Henrik |
|
From: Nicholas N. <nj...@ca...> - 2004-04-26 08:05:33
|
On Sun, 25 Apr 2004, Henrik Nordstrom wrote: > > In this case, Valgrind's pthread_cond_wait return EINVAL... is this right? > > EPERM is probably more appropriate. And SUSv3 seems to agree with me > here.. (see below) I've committed a change to do this. Thanks for the clarification. And I'll use the SUSv3 docs rather than man pages for such questions in the future! N |