rtems_iterate_over_all_threads

Aitor Viana aitor.viana.sanchez at esa.int
Wed Apr 22 21:15:53 UTC 2009


Hi all,

I'd like to contribute to this as I think it is an interesting discussion.

I understood (if am not wrong) from Leon that is the urgent task the one
suspending the rest of the tasks in order not to be interrupted when
performing all his processing and I/O.

Does not using a priority ceiling semaphore to protect this I/O solve the
problem? I know the ceiling of the semaphore should be the highest possible
so the task is not preempted by another tasks with higher priority.

The only problem I see with the Leon's solution is that, from real-time
point of view,  the schedulability analysis is kind of broken as a tasks
with low priority can block higher priority tasks without sharing any
resource with them. This is beyong priority inversion :D

Just a comment, I might be completely wrong.

wkr

aitor


On Wed, Apr 22, 2009 at 6:22 PM, Leon Pollak <leonp at plris.com> wrote:

> 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
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20090422/3773614f/attachment-0001.html>


More information about the users mailing list