Messages in this thread | | | Date | Wed, 21 Apr 2010 21:24:02 +0200 | Subject | Re: Considerations on sched APIs under RT patch | From | Primiano Tucci <> |
| |
> Actually, we do better than that. With adaptive locks, if the process on > the other CPU is still running, the high priority task will spin until > the other process releases the lock or goes to sleep. If it goes to > sleep, then the high prio task will also sleep, otherwise it just spins > and takes the lock when it is released. > > -- Steve
It sounds more reasonable now. I know that in a preemptible kernel even syscalls can be preempted. that absolutely fair except for those syscalls (such as setaffinity, setpriority) that control the scheduler.
Going back to my original problem, the real question is: Is it sure that calling a scheduler api won't induce a re-scheduling of the caller process (e.g. as in the case of a lock held by another processor)? It would be very unpleasant if the scheduling apis can induce re-scheduling, making the realization of a Real Time scheduling infrastructure completely un-deterministic.
If I have clearly understood your replies it seems that my problem is due to an *old* kernel version that still uses rw_lock into the setaffinity! Is it right?
Thank you for your extremely valuable support. Primiano
-- Primiano Tucci http://www.primianotucci.com
| |