Re: [ECOS] thread suspend/kill/delete

[Robin Farine <acnrf at dial dot eunet dot ch>]

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