lkml.org 
[lkml]   [2006]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 1/2] Introduce mutex_lock_timeout
Date
Hi Matthew,

On Saturday, 25. November 2006 04:55, Matthew Wilcox wrote:
> No comment on this?

Ok, I will comment it. But I'll NOT comment on the implementation.
I'll prove you instead, that timout based locking is non-sense.

What should the timout mutex_timeout() prevent? Usually the answer is
"if sombody hangs on a mutex forever ...?" and people tell you "ok, that is
a deadlock -> fix your code not to deadlock instead."
Then they tell you "Ok, but if somebody takes a mutex too long?"
and people will answer "ok, then this is a livelock -> fix your code not to
livelock."

Another answer is "I like to block until sth. happens wihin a specific time frame"
-> fine, this is accomplished by wait_event_timout (which blocks only you and
not every other user of the mutex).

So you see there is no real need for this and having it yould introduce an
instrument for hiding such bugs.

When you talk with untrusted binary only code such locks with timeouts
are sometimes needed, since you don't know the locking rules within
such code.

As this is not the case for kernel code, it is simply not needed.

I know why ACPI needs it (API requirement) and I think the qla???-driver
just needs to be fixed to work without it and nobody did it yet.


Regards

Ingo Oeser, who actually IS the implementation of mutex_lock_timeout()[1]

[1] Everytime (since 2001) someone suggest it, I discuss it away :-)
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2006-11-25 17:03    [W:0.077 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site