Breaking out of pthread_mutex_lock

Breaking out of pthread_mutex_lock

[Darren Hart]

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?

-- 
Darren Hart
Real-Time Linux Team
IBM Linux Technology Center

Re: Breaking out of pthread_mutex_lock

[Stephen Hemminger]

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?

Re: Breaking out of pthread_mutex_lock

[Darren Hart]

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) ?

-- 
Darren Hart
Real-Time Linux Team
IBM Linux Technology Center

Re: Breaking out of pthread_mutex_lock

[Clark Williams]

-----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.

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-----

Re: Breaking out of pthread_mutex_lock

[Gilles Carry]

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/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: Breaking out of pthread_mutex_lock

[Gilles Carry]

Hello Darren,

In futex_lock_pi(futex.c) when ERESTARTNOINTR which make the syscall to 
be reexecuted whatever comes after the sighandler ends.

One trick you can try (I've not tested it!) is use 
pthread_timedlock(mutex, abstime) and in sighandler, set abstime values 
to cause timeout. Since futex_lock_pi reads the time struct at each 
call, it will exit on timeout at reexecution.
Worth trying.

Gilles.

Darren Hart 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?
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~