Re: Breaking out of pthread_mutex_lock

[Gilles Carry <Gilles.Carry@bull.net>]

Clark Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Darren Hart wrote:
> 
>>On Thu, 2008-05-29 at 16:46 -0700, Stephen Hemminger wrote:
>>
>>>On Thu, 29 May 2008 23:41:55 +0000
>>>Darren Hart <dvhltc@us.ibm.com> wrote:
>>>
>>>
>>>>I find I need to be able to break out of the blocked state while waiting
>>>>to acquire a pthread_mutex.  I'm using PI mutexes and want to continue
>>>>to do so.  As I understand it, I can't use a signal to break out of the
>>>>lock as the man pages states:
>>>>
>>>>"If a signal is delivered to a thread waiting for a mutex,  upon  return
>>>>from  the  signal handler the thread shall resume waiting for the mutex
>>>>as if it was not interrupted."
>>>>
>>>>and that pthread_mutex_lock will not return EINTR.  I had considered
>>>>using cond variables, but I don't think they will provide the same PI
>>>>behavior (since the threads are not blocked on the mutex while awaiting
>>>>the pthread_cond_signal - right?).
>>>>
>>>>I'm sure I'm not the first to want to do this, does anyone know of a
>>>>common best practice for accomplishing such a thing?
>>>>
>>>
>>>setjmp/longjmp?
>>
>>Stephen,
>>
>>Hrmm... I confess to not having made use of them before.  I read up a
>>bit, and don't see right off how they would help in this situation.  I
>>assume you're suggesting the longjmp be used in a signal handler while
>>the thread is blocked on the mutex - where would it jump to, and how
>>would I ensure the integrity of the pthread_mutex structure (which
>>thinks my thread is waiting for it) ?
>>
> 
> 
> I don't see any way to recover from longjmp'ing out of a pthread_mutex_lock(). Maybe
> using robust futexes and killing the thread that was blocked?
> 
> I think it would be better to re-designed the code to use pthread_mutex_trylock()
> instead, so it doesn't block. That way you don't have a mutex in some wacky state.

The easiest thing to do (if you want to modify the syscall code) is to 
change the return(ERESTARTNOINTR) by return(ERESTARTSYS) in 
futex_lock_pi (futex.c) and in your application, play with sigaction's 
SA_RESTART flag.
Beware that pthread_mutex_trylock (glibc) might still return 0.

Gilles.


> 
> Clark
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkhAHBQACgkQHyuj/+TTEp3dVgCeI8tNnbSDOLThVrUqjWcM9xPA
> mVgAnjR2D4RxIBXAjC+S2jtCdTaB+1AD
> =rmf4
> -----END PGP SIGNATURE-----
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gilles.Carry
Linux Project team
mailto: gilles.carry@bull.net
Phone: +33 (0)4 76 29 74 27
Addr.: BULL S.A.  1 rue de Provence, B.P. 208 38432 Echirolles Cedex
http://www.bull.com
http://www.bullopensource.org/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~