Messages in this thread | | | Date | Sat, 22 May 1999 13:50:49 +0200 (MET DST) | From | Gerard Roudier <> | Subject | Re: Why 'wait queues' and not 'channels' |
| |
Hi David,
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/
| |