[ECOS] thread suspend/kill/delete

[ECOS] thread suspend/kill/delete

[Robin Farine]

Hi,

I feel a bit uncomfortable with the threads API functions cyg_thread_delete(),
cyg_thread_suspend() and cyg_thread_kill(). After looking at the sources, I
understand (please correct me if I missed something here) that a thread A may
suspend or kill another thread B without letting a chance to B to release any
resource (mutexes, dynamically alocated memory, ...), which could bring the
whole system into a very bad state.

Different ways of solving this problem follows.

1. Never use those primitives (a bit restrictive and why should the API define
   them then).

2. Only use them on the current thread. This implies that the application
   provides a mechanism for asking a thread to suspend, kill or delete itself
   (through flags or mbox). But this also means that we will write our own
   versions of this mechanism, again and again.

3. Introduce a pair of functions, cyg_thread_disable_suspend() and
   cyg_thread_enable_suspend(), and a counter for nested calls to delay
   actions. And perhaps the possibility to register a kill handler that gets
   called from cyg_thread_enable_suspend() so that, for instance, a C++ program
   could throw an exception to unwind its stack and thus release any resources
   that it allocated in an exception-safe manner (e.g. by making use of
   constructs such as STL's auto_ptr<>).

4. Applications make use of higher level APIs only, such as pthreads, but what's
   the point of the whole eCos C API then.


Any comment on how to deal with this?

Robin

Re: [ECOS] thread suspend/kill/delete

[Nick Garnett]

Robin Farine <acnrf@dial.eunet.ch> writes:

> Hi,
> 
> I feel a bit uncomfortable with the threads API functions cyg_thread_delete(),
> cyg_thread_suspend() and cyg_thread_kill(). After looking at the sources, I
> understand (please correct me if I missed something here) that a thread A may
> suspend or kill another thread B without letting a chance to B to release any
> resource (mutexes, dynamically alocated memory, ...), which could bring the
> whole system into a very bad state.

Indeed. This is why applications have to be careful in using them. In
general threads should not be unilaterally killed, but should be
allowed to call cyg_thread_exit() themselves.

> 
> Different ways of solving this problem follows.
> 
> 1. Never use those primitives (a bit restrictive and why should the API define
>    them then).

Yes we could delete them and say that the only facility for halting
threads is cyg_thread_exit(). But that would be unnecessarily
restrictive.

> 
> 2. Only use them on the current thread. This implies that the application
>    provides a mechanism for asking a thread to suspend, kill or delete itself
>    (through flags or mbox). But this also means that we will write our own
>    versions of this mechanism, again and again.

This all depends on the application and how it is written. Most
applications can easily arrange for threads to be given an exit
indication. This really does not need a general purpose mechanism to
support it.


> 
> 3. Introduce a pair of functions, cyg_thread_disable_suspend() and
>    cyg_thread_enable_suspend(), and a counter for nested calls to delay
>    actions. And perhaps the possibility to register a kill handler that gets
>    called from cyg_thread_enable_suspend() so that, for instance, a C++ program
>    could throw an exception to unwind its stack and thus release any resources
>    that it allocated in an exception-safe manner (e.g. by making use of
>    constructs such as STL's auto_ptr<>).

This is far too complicated. eCos is meant to be a simple system. If
you want something like this, then use POSIX.

> 
> 4. Applications make use of higher level APIs only, such as pthreads, but what's
>    the point of the whole eCos C API then.

Because the C API predates the POSIX support, and POSIX comes with a
lot of extra baggage that many applications will not want. The C API
is meant to be a thin veneer over the basic kernel primitives, and not
a complete programming environment.


-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

Re: [ECOS] thread suspend/kill/delete

[Robin Farine]

Nick Garnett <nickg@redhat.com> writes:

> Robin Farine <acnrf@dial.eunet.ch> writes:
> 
> > Hi,
> > 
> > I feel a bit uncomfortable with the threads API functions cyg_thread_delete(),
> > cyg_thread_suspend() and cyg_thread_kill(). After looking at the sources, I
> > understand (please correct me if I missed something here) that a thread A may
> > suspend or kill another thread B without letting a chance to B to release any
> > resource (mutexes, dynamically alocated memory, ...), which could bring the
> > whole system into a very bad state.
> 
> Indeed. This is why applications have to be careful in using them. In
> general threads should not be unilaterally killed, but should be
> allowed to call cyg_thread_exit() themselves.
> 
> > 
> > Different ways of solving this problem follows.
> > 
> > 1. Never use those primitives (a bit restrictive and why should the API define
> >    them then).
> 
> Yes we could delete them and say that the only facility for halting
> threads is cyg_thread_exit(). But that would be unnecessarily
> restrictive.
> 
> > 
> > 2. Only use them on the current thread. This implies that the application
> > provides a mechanism for asking a thread to suspend, kill or delete itself
> > (through flags or mbox). But this also means that we will write our own
> > versions of this mechanism, again and again.
> 
> This all depends on the application and how it is written. Most
> applications can easily arrange for threads to be given an exit
> indication. This really does not need a general purpose mechanism to
> support it.
> 

Ok, you comfort my I understanding (simplicity and extensibility) of the eCos
philosophy.

However, after some more thoughts about the restrictive character of removing
kill() and delete(), I cannot find any example of an application that safely
kills a thread from another thread where the killed thread cannot do it
itself. Those primitives allow programmers to (innocently) choose the easy and
wrong way rather than they offer them useful functionalities; a somewhat similar
but extreme case would be a thunder-mutex, fast as hell, but you can only
acquire or release it when you're sure that no other thread will access it
during the whole operation ;-)

For "pinailleurs" like me (sorry, don't know the English equivalent), what about
a CDL option that either disable completely those primitives so that the bad
application cannot link, or enable code in those functions that detects calls
applying to another thread and that:

  - CYG_ASSERT() or

  - log a warning message and return without doing anything or

  - call a user supplied routine and does its work depending on the result

As a motivation argument: one can expect, in a near future, that a single device
will probably combine telecoms, diary, tv, pacemaker, credit card, ...  I'd
certainly prefer to read on the LCD: "PACEMAKER thread: ignoring kill request"
rather than "PACEMAKER thread: killed, exiting gracefully" ;-) (really kidding
here)

[...]

To summerize, if eCos favors simplicity to completeness or whatever, then I vote
for those primitives to disappear or at least to become optional.


Robin

Re: [ECOS] thread suspend/kill/delete

[nicolas lacorne]

Robin Farine wrote:

> Nick Garnett <nickg@redhat.com> writes:
>
> > Robin Farine <acnrf@dial.eunet.ch> writes:
> >
> > > Hi,
> > >
> > > I feel a bit uncomfortable with the threads API functions cyg_thread_delete(),
> > > cyg_thread_suspend() and cyg_thread_kill(). After looking at the sources, I
> > > understand (please correct me if I missed something here) that a thread A may
> > > suspend or kill another thread B without letting a chance to B to release any
> > > resource (mutexes, dynamically alocated memory, ...), which could bring the
> > > whole system into a very bad state.
> >
> > Indeed. This is why applications have to be careful in using them. In
> > general threads should not be unilaterally killed, but should be
> > allowed to call cyg_thread_exit() themselves.
> >
> > >
> > > Different ways of solving this problem follows.
> > >
> > > 1. Never use those primitives (a bit restrictive and why should the API define
> > >    them then).
> >
> > Yes we could delete them and say that the only facility for halting
> > threads is cyg_thread_exit(). But that would be unnecessarily
> > restrictive.
> >
> > >
> > > 2. Only use them on the current thread. This implies that the application
> > > provides a mechanism for asking a thread to suspend, kill or delete itself
> > > (through flags or mbox). But this also means that we will write our own
> > > versions of this mechanism, again and again.
> >
> > This all depends on the application and how it is written. Most
> > applications can easily arrange for threads to be given an exit
> > indication. This really does not need a general purpose mechanism to
> > support it.
> >
>
> Ok, you comfort my I understanding (simplicity and extensibility) of the eCos
> philosophy.
>
> However, after some more thoughts about the restrictive character of removing
> kill() and delete(), I cannot find any example of an application that safely
> kills a thread from another thread where the killed thread cannot do it
> itself. Those primitives allow programmers to (innocently) choose the easy and
> wrong way rather than they offer them useful functionalities; a somewhat similar
> but extreme case would be a thunder-mutex, fast as hell, but you can only
> acquire or release it when you're sure that no other thread will access it
> during the whole operation ;-)
>

I think that one uses of cyg_thread_kill() is when  you desallocate stack from one
threads with another.
Because it would be uncorrect to desallocate  memory for a thread stack inside his
own code.
 Example:
  Threads A : before ending he mail killer thread his handler and his stack base then
set killer thread priority to maximum one.
   Killer thread : kill thread A and desallocate stack A then came back to minimal
priority.


Nico

>
> For "pinailleurs" like me (sorry, don't know the English equivalent), what about
> a CDL option that either disable completely those primitives so that the bad
> application cannot link, or enable code in those functions that detects calls
> applying to another thread and that:
>
>   - CYG_ASSERT() or
>
>   - log a warning message and return without doing anything or
>
>   - call a user supplied routine and does its work depending on the result
>
> As a motivation argument: one can expect, in a near future, that a single device
> will probably combine telecoms, diary, tv, pacemaker, credit card, ...  I'd
> certainly prefer to read on the LCD: "PACEMAKER thread: ignoring kill request"
> rather than "PACEMAKER thread: killed, exiting gracefully" ;-) (really kidding
> here)
>
> [...]
>
> To summerize, if eCos favors simplicity to completeness or whatever, then I vote
> for those primitives to disappear or at least to become optional.
>
> Robin

Re: [ECOS] thread suspend/kill/delete

[Robin Farine]

nicolas lacorne <Nicolas.Lacorne@sun.com> writes:

[...]

> >
> > However, after some more thoughts about the restrictive character of removing
> > kill() and delete(), I cannot find any example of an application that safely
> > kills a thread from another thread where the killed thread cannot do it
> > itself. Those primitives allow programmers to (innocently) choose the easy and
> > wrong way rather than they offer them useful functionalities; a somewhat similar
> > but extreme case would be a thunder-mutex, fast as hell, but you can only
> > acquire or release it when you're sure that no other thread will access it
> > during the whole operation ;-)
> >
> 
> I think that one uses of cyg_thread_kill() is when  you desallocate stack from one
> threads with another.
> Because it would be uncorrect to desallocate  memory for a thread stack inside his
> own code.
>  Example:
>   Threads A : before ending he mail killer thread his handler and his stack base then
> set killer thread priority to maximum one.
>    Killer thread : kill thread A and desallocate stack A then came back to minimal
> priority.

But in this example, since thread A will terminate, he will finally call the
Cyg_Thread::exit() function and thus enter the EXITED state. Your killer thread
could be called "reaper thread", he would scan the threads list for EXITED
threads in order to reclaim any memory dynamically allocated at the thread's
creation. The POSIX threads layer does just that, no need for the kill()
functionality.

[...]

Robin