> On Tue, 3 Mar 1998, MOLNAR Ingo wrote:
>
> > it was/is safe on any UP system, and it's also safe on 2.0 SMP.
>
> I'm not sure -- Linus's theory is:
>
> > So you have code that looks like
> >
> > repeat:
> > current->state = TASK_UNINTERRUPTIBLE;
> > if (empty) {
> > schedule();
> > goto repeat;
> > }
> >
> > but is actually executed as:
> >
> > CPU #0 CPU #1
> >
> > repeat:
> > if (empty)
> > empty = 0;
> > tsk->state = TASK_RUNNING;
> >
> > tsk->state = TASK_UNINTERRUPTIBLE;
> > schedule()
>
> but if the "if (empty)" is indeed re-ordered before the
> "tsk->state = TASK_UNINTERRUPTIBLE", it looks like even on UP, we
> can take an interrupt just at the point in which the above example
> took an interrupt and set "tsk->state = TASK_RUNNING" on CPU #1.
>
> That interrupt will still set tsk->state = TASK_RUNNING on our single
> CPU before we set the state to TASK_UNINTERRUPTIBLE, and then when we
> return, we will not fall through schedule() and enter an uninterruptible
> sleep.
Could this problem be avoided using some instruction like
"compare/exhange/while locked" to update empty and check if it zero all in
the same unit of work? I am thinking of that instruction which when broken
caused the Pentium lockup a few months ago.
john alvord
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu