[lkml]   [2004]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
Esben Nielsen wrote:

>Anyway, I am not sure recursive acquisition is such a good idea: It will
>make the mutex more expensive to use and promote sloppy coding where you
>don't really know what mutexes are held right now.
In my experience I haven't quite found this to be the case.
Rather allowing a lock/mutex/etc.. to be recursively acquired
within a given path can greatly simplify APIs. Such as
cases where a primitive acquires a lock internally which is
also know by and suited to protect data in the caller's context.
This avoids the "who has the lock?" information which must
otherwise get stuffed into the API. Nested function calls
simply observe correct lock usage at their respective levels
and all unwinds correctly.

The one notable place where this doesn't work is where
locks must be conditionally acquired in an out-of-order sequence.
However often these cases can be pushed out of the externally
visible API. Another operational consideration is maintaining
debug information in the lock. Keeping track of where each
lock acquisition was made is at odds with a fixed sized lock
data footprint. Still recursive acquisitions scale only
with available stack space so a fair upper limit approximation
is possible when running on fixed size stacks. Note I'm
refering to single-owner spinlocks/mutexes here rather than
reader/write locks.

>I think it is better that the sloppy coder discoveres that he
>deadlocks on himself before getting other sub-systems involved :-)
I agree. But I don't think the above precludes doing so.
Detecting violations of unbalanced lock/unlock calls isn't
really different than for non-recursive primitives.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:07    [W:0.669 / U:2.776 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site