rtems_iterate_over_all_threads
Manuel Coutinho
manuel.coutinho at edisoft.pt
Thu Apr 23 08:45:30 UTC 2009
Not meaning to be a pain but, you could solve this by making the urgent task
non-preemptive or making it the highest priority thread. In either of these
ways, no other threads will be able to run unless the urgent task
relinquishes the CPU.
By the way, another small note: suspending all other threads can be very
time consuming... (if you have too many threads)
>From the schedulability point of view, there are analyses in which
suspending threads are contemplated.
Between the option of suspending all other threads or making the urgent task
non-preemptive, I would take the last one
but, I dont know much about your
system
Hope this helped, at least a bit :)
Kind Regards
Manuel Coutinho
_____
From: Leon Pollak [mailto:leonp at plris.com]
Sent: Wednesday, April 22, 2009 5:59 PM
To: Manuel Coutinho
Cc: 'Thomas Dörfler'; rtems-users at rtems.com
Subject: Re: rtems_iterate_over_all_threads
On Wednesday April 22 2009, Manuel Coutinho wrote:
> 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
Because when, for example, doing I/O, the urgent task will allow task
switching, and this will change the situation, which is unacceptable.
The urgent task must process the "snapshot" of the moment it was started at.
Thanks.
Leon
--
Dr.Leon M.Pollak
Director
PLR Information Systems Ltd.
Tel.:+972-98657670 | POB 8130, H'Aomanut 9,
Fax.:+972-98657621 | Poleg Industrial Zone,
Mob.:+972-544739246 | Netanya, 42160, Israel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20090423/e41dd0c2/attachment-0001.html>
More information about the users
mailing list