Jeff
----- Original Message -----
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jeff Merkey <jmerkey@timpanogas.com>
Cc: <jmerkey@timpanogas.com>; <alan@lxorguk.ukuu.org.uk>;
<linux-kernel@vger.rutgers.edu>
Sent: Thursday, August 26, 1999 1:17 PM
Subject: Re: Locks used in the FAT file system are non-atomic and in fact,
don't work on SMP systems
> > I code reviewed sleep_on and wake_up in the linux kernel. I wrote the
SMP
> > kernel for NetWare 4, and discovered that unless you are holding the
lock
> > over the context switch, there is always a very small window between
> > something going to sleep and waking up where A) you can end up not
waking up
> > anyone or B) two guys can get through at the same time. The logic
doesn't
>
> Im confused. What exactly do you think wake_up and sleep_on guarantee
>
> wake_up wakes everyone on the queue at some arbitary instant
> sleep_on makes no guarantee about what occurs if you allow a wakeup while
> you are in sleep_on, until you are asleep.
>
> That is why code tends to use add_wait_queue/remove_wait_queue.
>
> > post operation will allow more than one guy to wake up in such a
scenario.
> > It has to do with how Intel's pipelines work and assumptions about
cached
> > data. MESI really is "messy" to deal with in some cases on SMP.
>
> The wait queue locks are store barriers because the lock will always have
> executed a lock btsl prior to being taken. The unlock likewise has done
> a lock btrl
>
>
>
> -
> 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/
>
-
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/