>On Tue, 30 Jul 2002, Russell Lewis wrote:
>
>You need to gain a lock just to read the bias field. You can't read
>something that somebody else will change while you are deciding
>upon what you read. It just can't work.
>
I intentionally made bias a non-precise field. It really doesn't matter
if it gets corrupted; it is just a rough idea of what's going on. So
there's no problem reading it without a lock. If the value you read is
wrong (or partial), then the worst that happends is bunch of NOPs before
you try for the lock (an undesirable, but not disastrous occurance).
>If we presume that it did work. What problem are you attempting
>to fix? FYI, there are no known 'lock-hogs'. Unlike a wait on
>a semaphore, where a task waiting will sleep (give up the CPU), a
>deadlock on a spin-lock isn't possible. A task will eventually
>get the resource. Because of the well-known phenomena of "locality",
>every possible 'attack' on the spin-lock variable will become
>ordered and the code waiting on the locked resource will get
>it in a first-come-first-served basis. This, of course, assumes
>that the code isn't broken by attempts to change the natural
>order.
>
Check out the title of the thread... Somebody has a real, reproducible
deadlock on a rw_lock where many readers are starving out a writer, and
the system hangs.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/