|
From: Russ F. <rus...@ho...> - 2004-06-24 02:59:56
|
Please try the sample program I have attached. It works well on Linux without Valgrind, but it aborts and reports an ownership (EPERM) error when you use Valgrind. Note that EPERM is different than EDEADLK, the deadlock condition that occurs when the same thread attempts to relock a locked mutex (locked previously by that same thread). What I am trying to do is perfectly legal, according to trial/error and the Linux manpage on threads, and is necessary in some cases. Hypothetically, consider a pool of threads that watch a work queue for Job objects. Available threads dequeue Job objects and call some method on them, and store some result internally. Prior to enqueueing, a client thread locks the Job object's "getresult" facility. (If the client tries to call getresult() before the Job has been processed by a thread, correct behavior is to block until some thread has a chance to "run" the Job.) When the Job is processed by a thread, the thread unlocks the getresult facility at the completion of doing work on the Job. At this point, the client thread can call getresult - or unblock because the mutex is now unlocked - and observe the work product. This scenario illustrates the need for mutexes that can be locked in one thread, and unlocked in another. According to the Linux documentation, pthread_mutex_lock says the "PTHREAD_MUTEX_FAST_NP" gives you the default POSIX behavior, which is: allow errant code to deadlock if the same thread tries to lock a mutex it already locked; unlock a mutex that a different thread has locked (or owns, rather). The ERRORCHECK and RECURSIVE mutexes work differently, in that they don't let you shoot yourself in the foot. Thanks for your help. Russ PS: This is a personal communication from an account that has keyword-based spam filtering enabled. Please preserve the original subject line when replying. (Adding "Re:" is okay.) _________________________________________________________________ MSN 9 Dial-up Internet Access fights spam and pop-ups now 3 months FREE! http://join.msn.click-url.com/go/onm00200361ave/direct/01/ |
|
From: Tom H. <th...@cy...> - 2004-06-24 06:18:14
|
In message <BAY...@ho...>
"Russ Fink" <rus...@ho...> wrote:
> Hypothetically, consider a pool of threads that watch a work queue for Job
> objects. Available threads dequeue Job objects and call some method on
> them, and store some result internally. Prior to enqueueing, a client
> thread locks the Job object's "getresult" facility. (If the client tries to
> call getresult() before the Job has been processed by a thread, correct
> behavior is to block until some thread has a chance to "run" the Job.) When
> the Job is processed by a thread, the thread unlocks the getresult facility
> at the completion of doing work on the Job. At this point, the client
> thread can call getresult - or unblock because the mutex is now unlocked -
> and observe the work product.
This is what a condition variable is designed for, and that would be
the normal way of performing this sort of signalling from one thread
to another.
> According to the Linux documentation, pthread_mutex_lock says the
> "PTHREAD_MUTEX_FAST_NP" gives you the default POSIX behavior, which is:
> allow errant code to deadlock if the same thread tries to lock a mutex it
> already locked; unlock a mutex that a different thread has locked (or owns,
> rather). The ERRORCHECK and RECURSIVE mutexes work differently, in that
> they don't let you shoot yourself in the foot.
Well according to the SuS pages PTHREAD_MUTEX_DEFAULT is the default
type and that does not allow unlocking in a different thread. That
mutex type is not required to return EPERM howevr - unlocking in a
different thread merely results in undefined behaviour. Details at:
http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_lock.html
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-06-24 08:38:36
|
On Wed, 23 Jun 2004, Russ Fink wrote: > Please try the sample program I have attached. It works well on Linux > without Valgrind, but it aborts and reports an ownership (EPERM) error when > you use Valgrind. The fact that it works normally doesn't mean it's a legal/well-formed program. Lots of programs do invalid things and still work, due to implementation flukes. Maybe > Note that EPERM is different than EDEADLK, the deadlock condition that occurs > when the same thread attempts to relock a locked mutex (locked previously by > that same thread). What I am trying to do is perfectly legal, according to > trial/error and the Linux manpage on threads, and is necessary in some cases. Can you quote the man page section that says this? Excuse my scepticism, but this behaviour would go against everything I've previously head about mutexes. After all, what good is a lock that can be unlocked by anyone? N |
|
From: Dennis L. <pla...@gm...> - 2004-06-24 09:53:24
|
At 10:38 24.06.2004, you wrote: >On Wed, 23 Jun 2004, Russ Fink wrote: > >>Please try the sample program I have attached. It works well on Linux >>without Valgrind, but it aborts and reports an ownership (EPERM) error >>when you use Valgrind. > >The fact that it works normally doesn't mean it's a legal/well-formed >program. Lots of programs do invalid things and still work, due to >implementation flukes. Maybe > >>Note that EPERM is different than EDEADLK, the deadlock condition that >>occurs when the same thread attempts to relock a locked mutex (locked >>previously by that same thread). What I am trying to do is perfectly >>legal, according to trial/error and the Linux manpage on threads, and is >>necessary in some cases. > >Can you quote the man page section that says this? Excuse my scepticism, >but this behaviour would go against everything I've previously head about >mutexes. After all, what good is a lock that can be unlocked by anyone? > >N > > >------------------------------------------------------- >This SF.Net email sponsored by Black Hat Briefings & Training. >Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self >defense, top technical experts, no vendor pitches, unmatched networking >opportunities. Visit www.blackhat.com >_______________________________________________ >Valgrind-users mailing list >Val...@li... >https://lists.sourceforge.net/lists/listinfo/valgrind-users Carpe quod tibi datum est |
|
From: Olly B. <ol...@su...> - 2004-06-25 03:42:32
|
On 2004-06-24, Nicholas Nethercote <nj...@ca...> wrote:
> On Wed, 23 Jun 2004, Russ Fink wrote:
>
>> What I am trying to do is perfectly legal, according to
>> trial/error and the Linux manpage on threads, and is necessary in some cases.
>
> Can you quote the man page section that says this?
I can quote the man page section which says the opposite (note especially
the last sentence):
man pthread_mutex_init:
On ``error checking'' mutexes, !pthread_mutex_unlock! actually checks
at run-time that the mutex is locked on entrance, and that it was
locked by the same thread that is now calling !pthread_mutex_unlock!.
If these conditions are not met, an error code is returned and the
mutex remains unchanged. ``Fast'' and ``recursive'' mutexes perform no
such checks, thus allowing a locked mutex to be unlocked by a thread
other than its owner. This is non-portable behavior and must not be
relied upon.
Cheers,
Olly
|