Thread Cancellation

Hi,

I have a multi-threaded process, in the process I am using pthread_cancel to
stop terminate threads when I need too. I have noticed that when I use
pidin I have lots of DEAD threads. Are these DEAD threads using any
resources, is there something I am not doing that I should be?

Thank you,


Simon Platten, Senior Software Engineer

VT Controls
Bessemer Way, Harfreys Industrial Estate, Great Yarmouth, Norfolk, NR31 0LX.
Tel: (0)1493 668811 Fax: (0)1493 651137
Email: simon.platten@vtcontrols.co.uk

Any views or opinions expressed are solely those of the author and do not
necessarily
represent those of VT Group, its holding company or any of its subsidiaries
or associates.

Did you pthread_join() on the terminated thread or set it’s original
attributes to via pthread_attr_setdetachstate() ?

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

Simon A. Platten <simon.platten@vtcontrols.co.uk> wrote in message
news:aris3a$a2r$1@inn.qnx.com

Hi,

I have a multi-threaded process, in the process I am using pthread_cancel
to
stop terminate threads when I need too. I have noticed that when I use
pidin I have lots of DEAD threads. Are these DEAD threads using any
resources, is there something I am not doing that I should be?

Thank you,


Simon Platten, Senior Software Engineer

VT Controls
Bessemer Way, Harfreys Industrial Estate, Great Yarmouth, Norfolk, NR31
0LX.
Tel: (0)1493 668811 Fax: (0)1493 651137
Email: > simon.platten@vtcontrols.co.uk

Any views or opinions expressed are solely those of the author and do not
necessarily
represent those of VT Group, its holding company or any of its
subsidiaries
or associates.

I didn’t specify any attributes when I created the thread I left the
parameter as NULL. Is the default state to join ? I’ll look into this.

“Adam Mallory” <amallory@qnx.com> wrote in message
news:arj0q5$hqk$1@nntp.qnx.com

Did you pthread_join() on the terminated thread or set it’s original
attributes to via pthread_attr_setdetachstate() ?

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net

Simon A. Platten <> simon.platten@vtcontrols.co.uk> > wrote in message
news:aris3a$a2r$> 1@inn.qnx.com> …
Hi,

I have a multi-threaded process, in the process I am using
pthread_cancel
to
stop terminate threads when I need too. I have noticed that when I use
pidin I have lots of DEAD threads. Are these DEAD threads using any
resources, is there something I am not doing that I should be?

Thank you,


Simon Platten, Senior Software Engineer

VT Controls
Bessemer Way, Harfreys Industrial Estate, Great Yarmouth, Norfolk, NR31
0LX.
Tel: (0)1493 668811 Fax: (0)1493 651137
Email: > simon.platten@vtcontrols.co.uk

Any views or opinions expressed are solely those of the author and do
not
necessarily
represent those of VT Group, its holding company or any of its
subsidiaries
or associates.
\

Unless you specify the thread as detachable, you must do a join for final
clean up. A good book is Programming With POSIX threads by Butenhof.

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

Simon A. Platten <simon.platten@vtcontrols.co.uk> wrote in message
news:arj223$gle$1@inn.qnx.com

I didn’t specify any attributes when I created the thread I left the
parameter as NULL. Is the default state to join ? I’ll look into this.

“Adam Mallory” <> amallory@qnx.com> > wrote in message
news:arj0q5$hqk$> 1@nntp.qnx.com> …

Did you pthread_join() on the terminated thread or set it’s original
attributes to via pthread_attr_setdetachstate() ?

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net

Simon A. Platten <> simon.platten@vtcontrols.co.uk> > wrote in message
news:aris3a$a2r$> 1@inn.qnx.com> …
Hi,

I have a multi-threaded process, in the process I am using
pthread_cancel
to
stop terminate threads when I need too. I have noticed that when I
use
pidin I have lots of DEAD threads. Are these DEAD threads using any
resources, is there something I am not doing that I should be?

Thank you,


Simon Platten, Senior Software Engineer

VT Controls
Bessemer Way, Harfreys Industrial Estate, Great Yarmouth, Norfolk,
NR31
0LX.
Tel: (0)1493 668811 Fax: (0)1493 651137
Email: > simon.platten@vtcontrols.co.uk

Any views or opinions expressed are solely those of the author and do
not
necessarily
represent those of VT Group, its holding company or any of its
subsidiaries
or associates.


\

Simon A. Platten <simon.platten@vtcontrols.co.uk> wrote:

Hi,

I have a multi-threaded process, in the process I am using pthread_cancel to
stop terminate threads when I need too. I have noticed that when I use
pidin I have lots of DEAD threads. Are these DEAD threads using any
resources, is there something I am not doing that I should be?

pthread_cancel() is a generally nasty thing to do to threads, as there
are real issues about the cleanup of resources allocated/owned by those
threads. Do they have any mutexes locked? Have they allocated any
memory? Have they opened any files? It is generally cleaner for a
thread that is “done” whatever it needs to do to cleanup after itself.

As far as the DEAD threads, they are using up a bit of space. Like
processes, there is proper handling for the termination of threads that
can allow another thread to determine why it died or get a return value,
and threads can be marked as “don’t care”.

pthread_join() is how you check the return value for a dead thread, and
clean them out of the thread table. If you don’t ever want to get/check
return values from threads, the thread can call pthread_detach(pthread_self()),
or some other thread can call pthread_detach(thread_id).

You can create threads already detached by modifying the attribute structure
for the thread by setting pthread_attr_setdetachstate().

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Thank you, I have implemented an attributes structure and set the state to
detached.

Regards,
Simon

“Adam Mallory” <amallory@qnx.com> wrote in message
news:arj5ke$kqk$1@nntp.qnx.com

Unless you specify the thread as detachable, you must do a join for final
clean up. A good book is Programming With POSIX threads by Butenhof.

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net

Simon A. Platten <> simon.platten@vtcontrols.co.uk> > wrote in message
news:arj223$gle$> 1@inn.qnx.com> …
I didn’t specify any attributes when I created the thread I left the
parameter as NULL. Is the default state to join ? I’ll look into this.

“Adam Mallory” <> amallory@qnx.com> > wrote in message
news:arj0q5$hqk$> 1@nntp.qnx.com> …

Did you pthread_join() on the terminated thread or set it’s original
attributes to via pthread_attr_setdetachstate() ?

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net

Simon A. Platten <> simon.platten@vtcontrols.co.uk> > wrote in message
news:aris3a$a2r$> 1@inn.qnx.com> …
Hi,

I have a multi-threaded process, in the process I am using
pthread_cancel
to
stop terminate threads when I need too. I have noticed that when I
use
pidin I have lots of DEAD threads. Are these DEAD threads using any
resources, is there something I am not doing that I should be?

Thank you,


Simon Platten, Senior Software Engineer

VT Controls
Bessemer Way, Harfreys Industrial Estate, Great Yarmouth, Norfolk,
NR31
0LX.
Tel: (0)1493 668811 Fax: (0)1493 651137
Email: > simon.platten@vtcontrols.co.uk

Any views or opinions expressed are solely those of the author and
do
not
necessarily
represent those of VT Group, its holding company or any of its
subsidiaries
or associates.




\

Hi,

I agree with your comments, I am using pthread_cancel() to abort a thread
that is performing a specific function. I am reasonably new to QNX. The
problem I have is this.

I issue a command to a process, that process creates a thread to perform the
command, which involves energising a digital output, going to sleep for a
short time then de-energising the output. The sleep time is variable.

If another command is issued to the process before the initial command has
completed then the initial command should be aborted and the new command
started.

This is why I use pthread_cancel() to abort the command. If there is a
cleaner way of aborting the thread whilst it is a sleep I’d like to hear it.

Thank you,
Simon

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:arjavg$o9k$1@nntp.qnx.com

Simon A. Platten <> simon.platten@vtcontrols.co.uk> > wrote:
Hi,

I have a multi-threaded process, in the process I am using
pthread_cancel to
stop terminate threads when I need too. I have noticed that when I use
pidin I have lots of DEAD threads. Are these DEAD threads using any
resources, is there something I am not doing that I should be?

pthread_cancel() is a generally nasty thing to do to threads, as there
are real issues about the cleanup of resources allocated/owned by those
threads. Do they have any mutexes locked? Have they allocated any
memory? Have they opened any files? It is generally cleaner for a
thread that is “done” whatever it needs to do to cleanup after itself.

As far as the DEAD threads, they are using up a bit of space. Like
processes, there is proper handling for the termination of threads that
can allow another thread to determine why it died or get a return value,
and threads can be marked as “don’t care”.

pthread_join() is how you check the return value for a dead thread, and
clean them out of the thread table. If you don’t ever want to get/check
return values from threads, the thread can call
pthread_detach(pthread_self()),
or some other thread can call pthread_detach(thread_id).

You can create threads already detached by modifying the attribute
structure
for the thread by setting pthread_attr_setdetachstate().

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Simon A. Platten <simon.platten@vtcontrols.co.uk> wrote:

Hi,

I agree with your comments, I am using pthread_cancel() to abort a thread
that is performing a specific function. I am reasonably new to QNX. The
problem I have is this.

I issue a command to a process, that process creates a thread to perform the
command, which involves energising a digital output, going to sleep for a
short time then de-energising the output. The sleep time is variable.

If another command is issued to the process before the initial command has
completed then the initial command should be aborted and the new command
started.

This is why I use pthread_cancel() to abort the command. If there is a
cleaner way of aborting the thread whilst it is a sleep I’d like to hear it.

If you change your logic so that instead of the thread sleeping, you simply
start a timer, and then have the expiration of the timer hit you with a pulse,
you can avoid thread cancellation issues. All you’d have to do is cancel
the timer, which is certainly less messy :slight_smile:

Cheers,
-RK

Thank you,
Simon

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:arjavg$o9k$> 1@nntp.qnx.com> …
Simon A. Platten <> simon.platten@vtcontrols.co.uk> > wrote:
Hi,

I have a multi-threaded process, in the process I am using
pthread_cancel to
stop terminate threads when I need too. I have noticed that when I use
pidin I have lots of DEAD threads. Are these DEAD threads using any
resources, is there something I am not doing that I should be?

pthread_cancel() is a generally nasty thing to do to threads, as there
are real issues about the cleanup of resources allocated/owned by those
threads. Do they have any mutexes locked? Have they allocated any
memory? Have they opened any files? It is generally cleaner for a
thread that is “done” whatever it needs to do to cleanup after itself.

As far as the DEAD threads, they are using up a bit of space. Like
processes, there is proper handling for the termination of threads that
can allow another thread to determine why it died or get a return value,
and threads can be marked as “don’t care”.

pthread_join() is how you check the return value for a dead thread, and
clean them out of the thread table. If you don’t ever want to get/check
return values from threads, the thread can call
pthread_detach(pthread_self()),
or some other thread can call pthread_detach(thread_id).

You can create threads already detached by modifying the attribute
structure
for the thread by setting pthread_attr_setdetachstate().

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.


Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

You can also use “pthread_setcanclestate()” to protect the section that you
don’t want
be canceled.

-xtang

Simon A. Platten <simon.platten@vtcontrols.co.uk> wrote in message
news:arkp8d$ep3$1@inn.qnx.com

Hi,

I agree with your comments, I am using pthread_cancel() to abort a thread
that is performing a specific function. I am reasonably new to QNX. The
problem I have is this.

I issue a command to a process, that process creates a thread to perform
the
command, which involves energising a digital output, going to sleep for a
short time then de-energising the output. The sleep time is variable.

If another command is issued to the process before the initial command has
completed then the initial command should be aborted and the new command
started.

This is why I use pthread_cancel() to abort the command. If there is a
cleaner way of aborting the thread whilst it is a sleep I’d like to hear
it.

Thank you,
Simon

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:arjavg$o9k$> 1@nntp.qnx.com> …
Simon A. Platten <> simon.platten@vtcontrols.co.uk> > wrote:
Hi,

I have a multi-threaded process, in the process I am using
pthread_cancel to
stop terminate threads when I need too. I have noticed that when I
use
pidin I have lots of DEAD threads. Are these DEAD threads using any
resources, is there something I am not doing that I should be?

pthread_cancel() is a generally nasty thing to do to threads, as there
are real issues about the cleanup of resources allocated/owned by those
threads. Do they have any mutexes locked? Have they allocated any
memory? Have they opened any files? It is generally cleaner for a
thread that is “done” whatever it needs to do to cleanup after itself.

As far as the DEAD threads, they are using up a bit of space. Like
processes, there is proper handling for the termination of threads that
can allow another thread to determine why it died or get a return value,
and threads can be marked as “don’t care”.

pthread_join() is how you check the return value for a dead thread, and
clean them out of the thread table. If you don’t ever want to get/check
return values from threads, the thread can call
pthread_detach(pthread_self()),
or some other thread can call pthread_detach(thread_id).

You can create threads already detached by modifying the attribute
structure
for the thread by setting pthread_attr_setdetachstate().

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

I issue a command to a process, that process creates a thread to perform
the
command, which involves energising a digital output, going to sleep for a
short time then de-energising the output. The sleep time is variable.

If another command is issued to the process before the initial command has
completed then the initial command should be aborted and the new command
started.

This is why I use pthread_cancel() to abort the command. If there is a
cleaner way of aborting the thread whilst it is a sleep I’d like to hear
it.

I think your design needs to be re-explored; asynchronously canceling a
threads execution should only be used if you have no other choice. How are
you protecting the fact that you might put hardware into an inconsistent
state (energizing or de-energizing) since the cancellation could occur
during those times? Did you program the worker thread with thread
cancelation points in mind?

Rob Krten’s suggestion (later posting) would be an improvement. Actually,
I’m not convinced you even need to be multithreaded if you use a timer for
notification and pulses.

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

Hi Simon,

I read your short description of the task. I understood that the thread you
want to suspend can be either working with outputs or “sleeping”. I don’t
know your configuration, but I guess it is not good idea to interrupt the
thread while it is working with hardware. I also don’t know how long does it
take to modify outputs, but again I guess that the thread spends more time
sleeping. Below is the one of the solutions. Actually, it is just an
illustration of what Robert Krten said here earlier.

Sincerely,

Serge

#include <errno.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <pthread.h>
#include <sys/select.h>
#include <sys/neutrino.h>

#define TIMER_PULSE 0

static int chid;
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

static void *thread( void *data )
{
struct _pulse pulse;
int rcvid, fd = 1;

while( 1 ) {
/*

  • The thread is “sleeping” here until timer pulse arrives
    */
    if( -1 != ( rcvid = MsgReceive( chid, &pulse, sizeof( struct
    _pulse ), NULL ))) {
    switch( pulse.code ) {
    case TIMER_PULSE:

/*

  • Writing digital output or whatever…
  • Timer also can be modified here.
    */
    pthread_mutex_lock( &mutex );
    write( fd, data, strlen( data ));
    pthread_mutex_unlock( &mutex );
    break;

default:

if( rcvid )
MsgReply( rcvid, ENOTSUP, NULL, 0 );

break;
}
}
}

return NULL;
}

int main( int argc, char **argv )
{
struct sigevent event;
int sec;
struct itimerspec timer;
char buff[ 1024 ];
int coid, timid;


if( -1 == ( chid = ChannelCreate( _NTO_CHF_DISCONNECT |
_NTO_CHF_UNBLOCK ))) {
perror( “ChannelCreate()” );
return EXIT_FAILURE;
}

if( -1 == ( coid = ConnectAttach( 0, 0, chid, _NTO_SIDE_CHANNEL, 0 )))
{
perror( “ConnectAttach()” );
return EXIT_FAILURE;
}

event.sigev_notify = SIGEV_PULSE;
event.sigev_coid = coid;
event.sigev_code = TIMER_PULSE;
event.sigev_priority = -1;

if( -1 == timer_create( CLOCK_REALTIME, &event, &timid )) {
perror( “timer_create()” );
return EXIT_FAILURE;
}

if( 0 != pthread_create( NULL, NULL, thread, buff )) {
perror( “pthread_create()” );
return EXIT_FAILURE;
}

for( sec = 1; ; sec++ ) {
pthread_mutex_lock( &mutex );

/*

  • stop timer
    */
    nsec2timespec( &timer.it_value, 0 );
    timer_settime( timid, 0, &timer, NULL );

/*

  • change output parameters
    */
    sprintf( buff, “time interval: %ds\n”, sec );

/*

  • change timer settings
    */
    timer.it_value.tv_sec = sec;
    timer.it_value.tv_nsec = 0;
    memcpy( &timer.it_interval, &timer.it_value, sizeof( struct
    timespec ));
    timer_settime( timid, 0, &timer, NULL );

pthread_mutex_unlock( &mutex );

/*

  • simulate some asyncronious behavior
    */
    sleep( 2 * sec + 1 );
    }

return EXIT_SUCCESS;
}

“Simon A. Platten” <simon.platten@vtcontrols.co.uk> wrote in message
news:arkp8d$ep3$1@inn.qnx.com

Hi,

I agree with your comments, I am using pthread_cancel() to abort a thread
that is performing a specific function. I am reasonably new to QNX. The
problem I have is this.

I issue a command to a process, that process creates a thread to perform
the
command, which involves energising a digital output, going to sleep for a
short time then de-energising the output. The sleep time is variable.

If another command is issued to the process before the initial command has
completed then the initial command should be aborted and the new command
started.

This is why I use pthread_cancel() to abort the command. If there is a
cleaner way of aborting the thread whilst it is a sleep I’d like to hear
it.

Thank you,
Simon

Hi,

Thank you for the suggestions, I will revisit the code, this is what the
thread currently does. For anyone interested the goal is to provide an
energised output for a specified pulse time to either open or close a
hyrdraulic valve.

This is a simplified version:

void* CmdThread(void* pArg)
{
int dChannelNo = *(int *)pArg;
OutputDO(dChannelNo, true); // Engerise output
sleep(dPulseTime); // Sleep for pulse duration
OutputDO(dChannelNo, false); // De-engergise output
}

The OutputDO() routine internally uses a mutex to lock the relevant data
structures used for the I/O board driver. If another command is received
whilst the thread is sleeping then the thread must be aborted as the I/O
board is only capable of driving one output at a time due to current. If
the thread is not aborted the new command may be de-energised when the
original thread wakes up if the pulse time is longer than the new command.

I will explore the solutions suggested.

Thanks,
Simon

“Simon A. Platten” <simon.platten@vtcontrols.co.uk> wrote in message
news:arkp8d$ep3$1@inn.qnx.com

Hi,

I agree with your comments, I am using pthread_cancel() to abort a thread
that is performing a specific function. I am reasonably new to QNX. The
problem I have is this.

I issue a command to a process, that process creates a thread to perform
the
command, which involves energising a digital output, going to sleep for a
short time then de-energising the output. The sleep time is variable.

If another command is issued to the process before the initial command has
completed then the initial command should be aborted and the new command
started.

This is why I use pthread_cancel() to abort the command. If there is a
cleaner way of aborting the thread whilst it is a sleep I’d like to hear
it.

Thank you,
Simon

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:arjavg$o9k$> 1@nntp.qnx.com> …
Simon A. Platten <> simon.platten@vtcontrols.co.uk> > wrote:
Hi,

I have a multi-threaded process, in the process I am using
pthread_cancel to
stop terminate threads when I need too. I have noticed that when I
use
pidin I have lots of DEAD threads. Are these DEAD threads using any
resources, is there something I am not doing that I should be?

pthread_cancel() is a generally nasty thing to do to threads, as there
are real issues about the cleanup of resources allocated/owned by those
threads. Do they have any mutexes locked? Have they allocated any
memory? Have they opened any files? It is generally cleaner for a
thread that is “done” whatever it needs to do to cleanup after itself.

As far as the DEAD threads, they are using up a bit of space. Like
processes, there is proper handling for the termination of threads that
can allow another thread to determine why it died or get a return value,
and threads can be marked as “don’t care”.

pthread_join() is how you check the return value for a dead thread, and
clean them out of the thread table. If you don’t ever want to get/check
return values from threads, the thread can call
pthread_detach(pthread_self()),
or some other thread can call pthread_detach(thread_id).

You can create threads already detached by modifying the attribute
structure
for the thread by setting pthread_attr_setdetachstate().

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Hello again,

Right I re-coded the command thread, and replaced the sleep call with this:

bool SendToSleep(unsigned udSeconds)
{
unsigned udSleepPeriod = 50;
unsigned udMsCtr = (udSeconds * 1000) / udSleepPeriod;

while (udMsCtr–)
{
sleep(udSleepPeriod * 1000);

if (GetAbortStatus() == true)
return true;
}
return false;
}

Basically, it sends the thread to sleep for 50 ms intervals, waking only to
check for an abort then going back to sleep until the sleep period has
expired. The GetAbortStatus is simply a mutex and variable check. It works
well and I have removed all the cancellation code.

Thanks again,
Simon

“Simon A. Platten” <simon.platten@vtcontrols.co.uk> wrote in message
news:arsmda$5qs$1@inn.qnx.com

Hi,

Thank you for the suggestions, I will revisit the code, this is what the
thread currently does. For anyone interested the goal is to provide an
energised output for a specified pulse time to either open or close a
hyrdraulic valve.

This is a simplified version:

void* CmdThread(void* pArg)
{
int dChannelNo = *(int *)pArg;
OutputDO(dChannelNo, true); // Engerise output
sleep(dPulseTime); // Sleep for pulse
duration
OutputDO(dChannelNo, false); // De-engergise output
}

The OutputDO() routine internally uses a mutex to lock the relevant data
structures used for the I/O board driver. If another command is received
whilst the thread is sleeping then the thread must be aborted as the I/O
board is only capable of driving one output at a time due to current. If
the thread is not aborted the new command may be de-energised when the
original thread wakes up if the pulse time is longer than the new command.

I will explore the solutions suggested.

Thanks,
Simon

“Simon A. Platten” <> simon.platten@vtcontrols.co.uk> > wrote in message
news:arkp8d$ep3$> 1@inn.qnx.com> …
Hi,

I agree with your comments, I am using pthread_cancel() to abort a
thread
that is performing a specific function. I am reasonably new to QNX.
The
problem I have is this.

I issue a command to a process, that process creates a thread to perform
the
command, which involves energising a digital output, going to sleep for
a
short time then de-energising the output. The sleep time is variable.

If another command is issued to the process before the initial command
has
completed then the initial command should be aborted and the new command
started.

This is why I use pthread_cancel() to abort the command. If there is a
cleaner way of aborting the thread whilst it is a sleep I’d like to hear
it.

Thank you,
Simon

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:arjavg$o9k$> 1@nntp.qnx.com> …
Simon A. Platten <> simon.platten@vtcontrols.co.uk> > wrote:
Hi,

I have a multi-threaded process, in the process I am using
pthread_cancel to
stop terminate threads when I need too. I have noticed that when I
use
pidin I have lots of DEAD threads. Are these DEAD threads using any
resources, is there something I am not doing that I should be?

pthread_cancel() is a generally nasty thing to do to threads, as there
are real issues about the cleanup of resources allocated/owned by
those
threads. Do they have any mutexes locked? Have they allocated any
memory? Have they opened any files? It is generally cleaner for a
thread that is “done” whatever it needs to do to cleanup after itself.

As far as the DEAD threads, they are using up a bit of space. Like
processes, there is proper handling for the termination of threads
that
can allow another thread to determine why it died or get a return
value,
and threads can be marked as “don’t care”.

pthread_join() is how you check the return value for a dead thread,
and
clean them out of the thread table. If you don’t ever want to
get/check
return values from threads, the thread can call
pthread_detach(pthread_self()),
or some other thread can call pthread_detach(thread_id).

You can create threads already detached by modifying the attribute
structure
for the thread by setting pthread_attr_setdetachstate().

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
\