lkml.org 
[lkml]   [1999]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.198 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site