Re: [ECOS] thread suspend/kill/delete

[nicolas lacorne <Nicolas dot Lacorne at sun dot com>]

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