canceling pthreads

[mitc...@yahoo.com]

I have been reading the book "Pthreads Programming" by Nichols,
et.al., and have found
it very helpful.

This question is for Solaris 10.

I am having trouble, however, trying to kill a thread. When I do, it
appears that the thread that was killed my have owned a lock (at
least, that is the behavior).

My questions are:

1. What good is using cancel type DEFERRED, if you can get whacked
during
pthread_cond_timedwait and still be left holding a lock?

My threads are set up as cancel state ENABLE and cancel type DEFERRED.

The book says that pthread_cond_timedwait (which I am using) is an
"automatic
cancellation point".

If my thread does the following (pseudo-code):

void mythread()
{
// do init stuff

while(1) {

pthread_mutex_lock()

while (!more work to do) {
pthread_cond_timedwait();

// check for timeout

// if no timeout, I have the lock, right?

// do my work

// free the lock

pthread_mutex_unlock();

} // end while

} // end while(1)

} // end function mythread

Since pthread_cond_timedwait is an automatic cancellation point, if my
thread
gets cancelled there, won't it have the lock tied up and now everyone
else will
be blocked?

Is it really possible that I have to wrap 'pthread_setcancelstate' to
DISABLED while
I have the lock? I would have thought that if pthreads knows to
cancel when you
are in the pthread_cond_timedwait call, it could dis-associate the
lock as well.

2. Using a debugger.

I tried using dbx to see if that would help me see what is going on.
It was helpful, but
I am still learning to use it.

Is there a way to use the debugger to see *exactly* where a thread is
when it gets
cancelled? (and by extension to see what resources it has?)

Thanks,

Mitch

[David Schwartz]

On Jul 22, 12:15 pm, "mitch...@yahoo.com" <mitch...@yahoo.com> wrote:

First, let me just say that I don't recommend using thread
cancellation *at* *all*. I don't think it makes any sense. If you
don't want a thread to keep doing what it's doing, just code it to do
something else. There is no reason to kill the thread.

> 1.  What good is using cancel type DEFERRED, if you can get whacked
> during
> pthread_cond_timedwait and still be left holding a lock?
>
> My threads are set up as cancel state ENABLE and cancel type DEFERRED.
>
> The book says that pthread_cond_timedwait (which I am using) is an
> "automatic
> cancellation point".

If you are going set a thread's cancel state to enabled, all the code
that thread runs must be designed to permit cancellation at every
cancellation point. If you're not willing to do that, then leave
cancellation disabled and use pthread_testcancel.

You should push a cleanup handler any time a thread takes a shared
resource and wants to allow itself to be canceled while it holds that
resource.

DS