rtems_iterate_over_all_threads

[Leon Pollak]

On Wednesday April 22 2009, Thomas Dörfler wrote:
> I really doubt that I have a bigger experience than you have, and please
>  don't take my critics against your proposal personally.
I respect you enough not to do this...:-)


> I think RTEMS has several methods to control, when a task should execute
> and when it shouldn't. Most of them are synchronous to each task's
> probgram flow (e.g. semaphores, waiting for events etc).
>
> Suspending a task from outside almost always means that you don't know
> the state this task is in when you suspend it. And if even multiple
> "control" tasks would suspend/resume arbitrary other tasks, you (no: I!)
> would soon loose track when which task is suspended...
>
> Consider your current problem: If I got you right, you want to make
> sure, that no other task is executed even when your task is waiting
> during I/O. Let's assume you use a serial termios channel for console
> output. If you suspend another task, while it is somewhere deep in
> termios, this task may even hold the output semaphore you are waiting on
> to get control of the output channel.
>
> In short: you can never be sure in which state you actually suspend a task.
>
> This is why I consider it bad practice to control other tasks via
> suspend/resume.
Well, I should intend to agree with you in general.
But still, these commands 9suspend/resume) exist in the API and people (like 
me) use them.

OK, we (users of s/r) need to be careful to avoid the case you described, but 
still be able to do what we want.

Just now, it is a serious problem for me:
I have an urgent job to be done, which can not be interrupted by other I/O and 
processing tasks despite the state they reside in. I can not block interrupts 
and task switching at all, as the urgent task must do some processing 
requiring these facilities.

When the urgent job finishes, I should like to return to the normal 
processing, which has been interrupted.

Just now, I can not, as previously suspended tasks will be resumed by exiting 
from the urgent task.

May be you see some other way to do this?

Many thanks.
Leon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20090422/74a076a6/attachment.html>