lkml.org 
[lkml]   [2005]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07
From
Date
On Wed, 2005-03-30 at 08:50 +0200, Ingo Molnar wrote:
> * Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > OK, I'm declaring defeat here. I've been fighting race conditions all
> > day, and it's now 1 in the morning where I live. It looks like this
> > implementation has no other choice but to have the waking up "pending
> > owner" take the wait_list lock once again. How heavy of a overhead is
> > that really?
>
> as i mentioned it before, taking a lock is not a big issue at all. Since
> you have to touch the lock data structure anyway (and all of it fits
> into a single cacheline), it doesnt really matter whether it's atomic
> flag setting/clearing, or raw spinlock based.c0267ad4
>

OK, I've implemented adding the write_lock, but I still have a nasty
race condition, and I finally figured out why!

The damn BKL! Here's the situation I'm having.

Process A grabs BKL then tries to grab another semaphore (say sem X)
But process B has sem X so process A sleeps.
Since semaphores don't have the restriction of saving the BKL, the BKL
gets released from process A.
Process C comes along and grabs the BKL.
Finally B releases sem X and process A becomes the new "pending owner"
and wakes up.
When A schedules in it tries to grab the BKL but blocks. Now it is at
the point where A doesn't actually own either the BKL or sem X.
When C releases the BKL and gives it to A, A is now the pending owner
of both the BKL and sem X.

When this occurs, all hell breaks loose.

I believe I can solve this by making the BKL a special case and not
implement the pending owner at all for it.

> later on, once things are stable and well-understood, we can still
> attempt to micro-optimize it.
>

Heck, I'll make it bloat city till I get it working, and then tone it
down a little :-) And maybe later we can have a better solution for the
BKL.

-- Steve


-
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/

\
 
 \ /
  Last update: 2005-04-06 13:31    [W:0.114 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site