lkml.org 
[lkml]   [2010]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Considerations on sched APIs under RT patch
    From
    Date
    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.



    \
     
     \ /
      Last update: 2010-04-21 10:51    [W:0.022 / U:91.112 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site