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 don’t 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