Messages in this thread | | | Subject | Re: Considerations on sched APIs under RT patch | From | Peter Zijlstra <> | Date | Wed, 21 Apr 2010 10:49:32 +0200 |
| |
On Wed, 2010-04-21 at 07:16 +0200, Primiano Tucci wrote: > Hi steve > > read_locks are converted into "special" rt_mutexes. The only thing > > special about them, is the owner may grab the same read lock more than > > once (recursive). > > > > If a lower priority process currently holds the tasklist_lock for write, > > when a high priority process tries to take it for read (or write for > > that matter) it will block on the lower priority process. But that lower > > priority process will acquire the priority of the higher priority > > process (priority inheritance) and will run at that priority until it > > releases the lock. Then it will go back to its low priority and the > > higher priority process will then preempt it and acquire the lock for > > read. > > In your example you implied that the low priority process, holding the > lock for write, runs on the same CPU of the higher priority process > that wants to lock it for read. This is clear to me. > My problem is, in a SMP environment, what happens if a process (let's > say T1 on CPU #1) holds the lock for write (its priority does not > matter, it is not a PI problem) and now a process T0 on cpu #0 wants > to lock it for read? > The process T0 will be blocked! But who will run now on CPU 0, until > the rwlock is held by T1? Probably the next ready process on CPU #'0. > Is it right?
Yes. This is the reality of SMP systems, nothing much you can do about that. System resources are shared between all cpus, irrespective of task affinities.
| |