[lkml]   [2006]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PI patch against 2.6.16-rt9
On Wed, 2006-03-29 at 00:34 +0100, Esben Nielsen wrote:
> > Your method is tempting, but I do not see how it works out right now
> It works for PI.

Well, works and effective are two things. In the worst case it
introduces scheduler floods.

> It might give false positives for deadlock detection even
> without signals involved. But that might be solved by simply checking
> again.

Which is even more broken. Rechecking is less deterministic as the
global lock fall back solution.

> If it is stored on a task when they blocked on a lock it
> could be seen if they had released and reobtained the task since the last
> traversal.


> If I should choose between a 100% certain deadlock detection and
> rescheduling while doing PI I would choose that latter as that gives a
> deterministic RT system. Are there at all applications depending on
> deadlock detection or is it only for debug perposes anyway?

No, userspace can request deadlock checking and we have to return
-EDEADLK in that case.

A deadlock condition was detected or the current thread already
owns the mutex.

Returning false positives might break well designed applications and
prevent real deadlock detection.

Btw, your get/put_task proposal adds two atomic ops. Atomic ops are
implicit memory barriers and therefor you add two extra slow downs into
the non conflict case.


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: 2006-03-29 02:01    [W:0.045 / U:2.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site