Date: Sat, 20 May 00 18:15 IST From: veliath@jasmine.hclt.com To: arch@FreeBSD.ORG Subject: Re: BSD* mutex summary Message-ID: <0005201816.AA08131@jasmine.hclt.com>
next in thread | raw e-mail | index | archive | help
Quoting Terry Lambert: u> If the resource itself has reservations made by a high priority u> process, then the operation is called "priority inheritance", since u> by virtue of the low priority process using the resource, it will u> inherit the priority of the highest priority process holding a u> reservation on the ersource (in intention-mode locking, this is a SIX u> lock: Shared, Intention eXclusive). When the resource is released, u> the priority of the lower priority process is reduced to its previous u> value. Isn't this akin to SVR4/MP kernels raising the spl before acquiring a lock, to the highest spl at which that lock is acquired? i.e. if an interrupt routine and a "base" routine share a lock, the base routine raises the spl to protect itself against the interrupt routine being scheduled on the same processor as it is. Ofcourse in this case the "reservations" are done at compile time. u> If the resource does not have a reservation pending, and is allocated u> to a low priority process, then when a high priority process needs u> the resource, the low priority priority process is "lent" the high u> priority process' priority _until it releases the resource_. This u> operation is called "priority lending". And isn't this what the Solaris documentation calls "priority inheritance"? I understand Solaris uses this to avoid having code that needs run only at low spls run at high spls unless necessary. [if at all they have the concept of "spl"s anymore - even internaly. Its not documented in their Driver Writers Guide.] Correct me if I am wrong. I am trying to understand whats being defined here. u> In the general case, priority inheritance is more efficient than u> priority lending, IFF the resource is going to be repeatedly released u> and reacquired. u> u> IFF the resource is _not_ going to be released and reacquired, then u> one can delay, perhaps permanently, the need for a lower priority u> process to obtain higher priority. This permits priority lending to u> be more efficient, in that the processes are "truer to their intended u> priorities" than they might otherwise be. I do not understand this. Could you describe a scenario where "priority inheritance" (your definition) is more efficient than "priority lending" (again your definition). Thank you, veliath u> Priority inheritance is generally associated with Djikstra's u> "Banker's Algorithm", which is a prereservation of all needed u> resources. u> u> Priority lending is not; since Djikstra's algorithm has some u> potentially significant negative effects on concurrency (#1 wants "A" u> then "B", #2 wants "B", #2 could run to completion before #1 asks for u> "B", but can not run because "B" has been precomitted to #1 to avoid u> deadlock), priority lending is to be preferred for most cases (an u> exception is for resources which will be held for long periods of u> time, or repeatedly held and released, at which point the in-band u> cost of lending is once per transaction, whereas the priority u> inheritance setup costs can be amortized over all transactions). u> u> u> A FreeBSD example similar to "priority inheritance" is when a process u> opens /dev/io, it gains access to the I/O bus. When it closes u> /dev/io, this access is revoked. u> u> u> A FreeBSD example similar to "priority lending" is seen in the u> "FASTINTR" processing. u> u> u> Terry Lambert u> terry@lambert.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0005201816.AA08131>