pthread_mutex_lock + pthread_cancel
Greg
Hi,
I've a question for specialists (or not) here:
My main thread creates another one (with attr PTHREAD_CREATE_DETACHED),
and then put itself in waiting condition (cond_timedwait).
While the created thread do some works. (after having put itself
PTHREAD_CANCEL_ENABLE & PTHREAD_CANCEL_ASYNCHRONOUS).
In that works, it has some
{
pthread_mutex_lock (a_mtx);
works_on_shared_variable;
pthread_mutex_unlock (a_mtx);
}
In the main thread, if the pthread_cond_timedwait returns while the
created one is always working (that was to the created thread to signal
the condition), it's going to pthread_cancel it.
My question is :
As I've enabled cancel_asynchronous, in case the created thread was in
the "works_on_shared_variable" part, do the cancel also remove the lock
the thread had to the 'a_mtx' ??
I would say yes, but I'm not sure ..
Thanks for your informations.
Greg.
Loic Domaigne
I shall soon charge 1$ per question correctly answered ;-)
> I've a question for specialists (or not) here:
> My main thread creates another one (with attr PTHREAD_CREATE_DETACHED),
> and then put itself in waiting condition (cond_timedwait).
[snip]
> My question is :
> As I've enabled cancel_asynchronous, in case the created thread was in
> the "works_on_shared_variable" part, do the cancel also remove the lock
> the thread had to the 'a_mtx' ??
> I would say yes, but I'm not sure ..
No. As usual, POSIX decided to "make life for programmer as hard as
possible, so that they'll soon regret to ever having started with
Pthreads" ;-)
Which mean: if a thread exits or is cancelled while it owns a locked
mutex, the mutex will remain locked forever. Forever, because the only
thread that could unlock the mutex isn't longer there... With the
corrollary: any threads locking that mutex afterwards shall deadlock
forever too...
That's probably not what you want.
And ... Hmmm... I guess your next question... And the answer is:
Cleanup handlers. Have a look at the following Pthreads APIs:
void pthread_cleanup_push(void (*routine) (void *), void *arg);
void pthread_cleanup_pop(int execute);
Cheers,
Loic.
P.S:
Assume that someone is the restroom and has locked the door in order
to keep privacy. Suddently, heart attack: he dies. Would you really
expect to find the door unlocked if you go to the restroom?
--
Article posté via l'accès Usenet http://www.mes-news.com
Accès par Nnrp ou Web
Greg Law
> Hello Greg,
>
> I shall soon charge 1$ per question correctly answered ;-)
Actually, this is a different Greg who's posted!
(It confused me too at first; I spent about 1s reading in a state of
total confusion -almost panic- thinking "I don't remember writing this",
before I twigged there was another poster with my name!)
Greg != Greg Law :-)
g
Loic Domaigne
> > I shall soon charge 1$ per question correctly answered ;-)
> Actually, this is a different Greg who's posted!
To both Gregs: excuse me... I just have been more careful.
> (It confused me too at first; I spent about 1s reading in a state of
> total confusion -almost panic- thinking "I don't remember writing this",
> before I twigged there was another poster with my name!)
Hmm.... You wouldn't have been the first to which it happens ;-)
Cheers,
Loic.
Greg
Loic Domaigne wroted friendly :
> No. As usual, POSIX decided to "make life for programmer as hard as
> possible, so that they'll soon regret to ever having started with
> Pthreads" ;-)
>
> Which mean: if a thread exits or is cancelled while it owns a locked
> mutex, the mutex will remain locked forever. Forever, because the only
> thread that could unlock the mutex isn't longer there... With the
> corrollary: any threads locking that mutex afterwards shall deadlock
> forever too...
>
> That's probably not what you want.
yupp :-\
> And ... Hmmm... I guess your next question... And the answer is:
> Cleanup handlers. Have a look at the following Pthreads APIs:
Thx a lot, that what I was afraid from ... second :-\
>
> void pthread_cleanup_push(void (*routine) (void *), void *arg);
> void pthread_cleanup_pop(int execute);
So I'm going to have a look at those.
By the way, is this good to use asynchronous cancelable state so with
such cleanup handler ? (I _really_ (well as far as nothing would prevent
me to do) want to be able to have asynchronous cancelable threads)
> Cheers,
> Loic.
>
> P.S:
> Assume that someone is the restroom and has locked the door in order
> to keep privacy. Suddently, heart attack: he dies. Would you really
> expect to find the door unlocked if you go to the restroom?
Hmm, I would have set-up a way to open the door from outside in that
case so, don't you think ? ;-)
Thanks anyway.
Greg.
Greg
Loic Domaigne a écrit :
> Hi Greg and Greg!
The Gregs are online..
>>Actually, this is a different Greg who's posted!
No no this well me ;-)
> To both Gregs: excuse me... I just have been more careful.
Errare humanum est.
>>(It confused me too at first; I spent about 1s reading in a state of
>>total confusion -almost panic- thinking "I don't remember writing this",
>>before I twigged there was another poster with my name!)
:-)
> Hmm.... You wouldn't have been the first to which it happens ;-)
>
>
> Cheers,
> Loic.
Greetings to both of you.
Greg
>> void pthread_cleanup_push(void (*routine) (void *), void *arg);
>> void pthread_cleanup_pop(int execute);
> So I'm going to have a look at those.
Hmm, already read.
I'm a little bit ashamed this looks like so easy ...
And this is why I've another question :
Where is the trap ?
Loic Domaigne
> By the way, is this good to use asynchronous cancelable state so with
> such cleanup handler ? (I _really_ (well as far as nothing would prevent
> me to do) want to be able to have asynchronous cancelable threads)
Concerning asynchronous cancellation: that's, in most case, a *real* bad
idea. I mean, definitively, a *real, real, real* bad idea.
The main raison, is that you don't really know when the cancellation
occurs. It might well happen in the middle of a malloc(), wich could have
dramatic consequences...
In fact, if you really insist on having asynchronous cancellation, you
must write the function so that it is "async-cancel-safe"... That's not
so easy, because almost none of the POSIX/SUS APIs are required to be
async-cancel-safe. The list of async-cancel-safe functions is rather
tiny:
pthread_cancel(), pthread_setcancelstate(), and pthread_setcanceltype()
Unless you block or defer cancellation, you have no guarantee at all
that cancelling the thread is safe if it is right in the middle of
another POSIX/SUS functions than the three listed above....
As you might guess, you can't really do a lot.
Only very specific applications might take advantage of asynchronous
cancellation (one class that come to my mind: purely compute-bound
thread involving none of the math functions.).
In most of the case, asynchronous cancellation should be at best
avoided.
Cheers,
Loic.
> > P.S:
> > Assume that someone is the restroom and has locked the door in order
> > to keep privacy. Suddently, heart attack: he dies. Would you really
> > expect to find the door unlocked if you go to the restroom?
> Hmm, I would have set-up a way to open the door from outside in that
> case so, don't you think ? ;-)
Don't know exactly US door system - though I don't remember seeing such
a system as I was in the States. But in Europe, in 99.99% cases, the
only possibility is to open the door/lock using a "brute force" method.
A notion that, fortunately, POSIX never introduced... Otherwise, we
would have problably a lot of pthread_mutex_force_unlock() everywhere
:-)
Loic Domaigne
I see, you begin to understand the philosophy of the Single Unix
Specification ;-)
The trap is: you know for - your procedure - what you need to
"corrected" in the cleanup handler, to recover from a broken state
before the thread got cancelled.
However, as I explained in my previous answer, almost none of the
SUS/POSIX are required to be async-cancel-safe. Which means, those
standard function don't have any cleanup handlers, though they might
need one...
Imagine the scenario; you cancel the thread while it is doing a
printf(). Many implementation used a mutex to make printf()
thread-safe... If your thread took the look in printf(), and got
cancelled... then all your thread calling printf() afterwards shall
simply deadlock...
You as see, asynchronous cancellability isn't just a matter of
installing the "right cleanup handler" ....
HTH,
Loic.
Patrick TJ McPhee
Greg <gr...@nowhere.nowhere> wrote:
% My main thread creates another one (with attr PTHREAD_CREATE_DETACHED),
% and then put itself in waiting condition (cond_timedwait).
%
% While the created thread do some works. (after having put itself
% PTHREAD_CANCEL_ENABLE & PTHREAD_CANCEL_ASYNCHRONOUS).
%
% In that works, it has some
% {
% pthread_mutex_lock (a_mtx);
% works_on_shared_variable;
% pthread_mutex_unlock (a_mtx);
% }
You are not allowed to do this with asynchronous cancellation enabled.
This is one case where doing what you're not allowed to do is certain
to lead to program failure. There is simply no way to recover from
this.
What you can do is
pthread_mutex_lock (a_mtx);
pthread_cleanup_push(pthread_mutex_unlock, a_mtx);
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
works_on_shared_variable;
pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, NULL);
pthread_cleanup_pop (1);
assuming that all the work on the shared variable is allowed to be
cancelled asynchronously.
--
Patrick TJ McPhee
East York Canada
pt...@interlog.com
Greg
<cutted>
>
> Unless you block or defer cancellation, you have no guarantee at all
> that cancelling the thread is safe if it is right in the middle of
> another POSIX/SUS functions than the three listed above....
>
> As you might guess, you can't really do a lot.
I see, Ok I'll forget asynchronous cancelable threads so.
> Only very specific applications might take advantage of asynchronous
> cancellation (one class that come to my mind: purely compute-bound
> thread involving none of the math functions.).
and mine are not, so ..
> In most of the case, asynchronous cancellation should be at best
> avoided.
>
>
> Cheers,
> Loic.
Thanks a lot Loic.
Greg.
shireesh
I have a similiar problem which Greg(the first of the two) had.
But my problem is that the thread created calls a library(3rd party)
function..It could be consuming mutex/or some IPC over there(in that
call) and
in the main thread, I have to cancel the child thread after my timer
expires.
Now, It is simply impossible for me to cleanup those unkknown(3rd
party) IPC resources in my cleanup handler.
any way out?
thanks for your time.
Shireesh
Sebastien Decugis
I would disable the cancelability before calling library functions, then
re-enable it afterwards (or alternatively, ensure the library functions
are cancel-safe).