rtems_iterate_over_all_threads

[Manuel Coutinho]

  _____  

From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org]
On Behalf Of Leon Pollak
Sent: Wednesday, April 22, 2009 5:22 PM
To: Thomas Dörfler
Cc: rtems-users at rtems.com.
Subject: Re: rtems_iterate_over_all_threads

 

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.



My 2 cents, if I may :) =>

  Why not make that task (that does the urgent job) with a high priority? It
seams the standard way of increasing responsiveness while allowing
interrupts and task switching


 

 

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/5c3e1ea3/attachment-0001.html>