Re: PI patch against 2.6.16-rt9
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
- Date: Tue, 28 Mar 2006 23:36:42 +0200
On Tue, 2006-03-28 at 22:17 +0100, Esben Nielsen wrote:
I think we talk about the situation
No, we talk about existing lock chains L(0) --> L(n).
B locks 1 C locks 2 D locks 3
B locks 2, boosts C and block
A locks 2
A is boost B
A drop it's spinlocks and is preempted
C unlocks 2 and auto unboosts
B is running
B locks 3, boosts C and blocks
A gets a CPU again
A boosts B
A boosts D
Is there anything wrong with that?
And in the case where A==D there indeed is a deadlock which will be
detected.
If you get to L(x) the underlying dependencies might have changed
already as well as the dependencies x ... n. We might get false
positives in the deadlock detection that way, as a deadlock is an
"atomic" state.
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: PI patch against 2.6.16-rt9
- From: Esben Nielsen
- Re: PI patch against 2.6.16-rt9
- References:
- Re: PI patch against 2.6.16-rt9
- From: Esben Nielsen
- Re: PI patch against 2.6.16-rt9
- Prev by Date: Re: [Devel] Re: [RFC] Virtualization steps
- Next by Date: Re: 2.6.16: Oops - null ptr in blk_recount_segments?
- Previous by thread: Re: PI patch against 2.6.16-rt9
- Next by thread: Re: PI patch against 2.6.16-rt9
- Index(es):