You wrote:
> > Essentially the crucial difference is, under Linux we:
> > add_to_wait_queue
> > while(1) {
> > check event, break if event happened
> > break if signal arrived
> > schedule();
> > }
> > remove_from_wait_queue
> > On first sight, you may think nothing interesting is happening here.
Why should I think so ? ;)
On Sun, 16 May 1999, Gerard Roudier wrote:
> My opinion is that we got race conditions we deserve if we donnot lock
> when we should do so. The above code just enforces some ordering of
> operations using some locks or barriers that are not visible. It may be
> correct, but it is complex and relies to much on synchronisation done in
> our back.
Just a question, since I didn't even find the invisible ;-) compiler
barrier and/or ordering rule that prooves this code will always behave
as expected:
tsk->state = TASK_UNINTERRUPTIBLE;
run_task_queue(&tq_disk);
if (buffer_locked(bh)) {
schedule();
goto repeat;
}
run_task_queue() in inlined and calls macros and buffer_locked() is also a
macro. Nothing obvious in the code, even looking into run_task_queue()
code seems to enforce the order we expect at compilation step for
these 2 ones:
tsk->state = TASK_UNINTERRUPTIBLE;
if (buffer_locked(bh)) {
Imagine it would be ever possible and correct for a clever compiler to
generate:
if (buffer_locked(bh)) {
tsk->state = TASK_UNINTERRUPTIBLE;
You may want to let me know if we may ever deserve ;-) this race on not ?
Regards,
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/