Re: scheduler (sched_4bsd) questions

From: John Baldwin (jhb_at_FreeBSD.org)
Date: 10/04/04

  • Next message: M. Warner Losh: "Re: /sys/conf is getting unwieldy to handle..." 
    To: freebsd-arch@FreeBSD.org
Date: Mon, 4 Oct 2004 11:31:35 -0400

    On Friday 01 October 2004 12:13 am, Stephan Uphoff wrote:
    > On Wed, 2004-09-29 at 18:14, Stephan Uphoff wrote:
    > > I was looking at the MUTEX_WAKE_ALL undefined case when I used the
    > > critical section for turnstile_claim().
    > > However there are bigger problems with MUTEX_WAKE_ALL undefined
    > > so you are right - the critical section for turnstile_claim is pretty
    > > useless.
    >
    > Arghhh !!!
    >
    > MUTEX_WAKE_ALL is NOT an option in GENERIC.
    > I recall verifying that it is defined twice. Guess I must have looked at
    > the wrong source tree :-(
    > This means yes - we have bigger problems!
    >
    > Example:
    >
    > Thread A holds a mutex x contested by Thread B and C and has priority
    > pri(A).
    >
    > Thread C holds a mutex y and pri(B) < pri(C)
    >
    > Thread A releases the lock wakes thread B but lets C on the turnstile
    > wait queue.
    >
    > An interrupt thread I tries to lock mutex y owned by C.
    >
    > However priority inheritance does not work since B needs to run first to
    > take ownership of the lock.
    >
    > I is blocked :-(

    Ermm, if the interrupt happens after x is released then I's priority should
    propagate from I to C to B. If the interrupt happens before x is released,
    then the final bit of propagate_priority() should handle it since it resorts
    the turnstile's thread queue so that C will be awakened rather than B. 

    -- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: M. Warner Losh: "Re: /sys/conf is getting unwieldy to handle..."

    Relevant Pages

    • [PATCH 4/8] adaptive real-time lock support
      ... The Real Time patches to the Linux kernel converts the architecture ... compromising the integrity of critical sections protected by the lock. ... while retaining both the priority inheritance protocol as well as the ... the RT Mutex has been ...
      (Linux-Kernel)
    • Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)
      ... need the exclusion provided by the lock for a very long time so it drops it to avoid needless contention, then reaquires it when it finally does need the lock. ... other threads that were blocked on that mutex could do useful work in the interim without impacting A's progress at all. ... the SUS discussion of priority inheritance would never need ... In a priority-driven environment, a direct use of traditional primitives like mutexes and condition variables can lead to unbounded priority inversion, where a higher priority thread can be blocked by a lower priority thread, or set of threads, for an unbounded duration of time. ...
      (Linux-Kernel)
    • [PATCH -mm] Update rt-mutex-design.txt as per Randy Dunlap suggestions
      ... The classic example of unbounded priority inversion is were you have three ... A tries to grab a lock that C ... the PI locks will be called a mutex. ... The mutex structure contains a pointer to the owner of the mutex. ...
      (Linux-Kernel)
    • Re: FUSYN and RT
      ... >> to hold a fusyn lock, then block on an RT lock. ... >> will be problems when the RT mutex tries to restore the priority. ...
      (Linux-Kernel)
    • Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)
      ... time without requiring the lock. ... A should not be immediately reacquiring the lock if it doesn't actually need it. ... other threads that were blocked on that mutex could do useful work in the interim without impacting A's progress at all. ... the SUS discussion of priority inheritance would never need ...
      (Linux-Kernel)
    Loading