linas at austin.ibm.com linas at austin.ibm.com
Sat Jan 10 11:31:31 EST 2004

On Wed, Jan 07, 2004 at 09:09:32AM -0600, Dave Engebretsen wrote:
> Anton Blanchard wrote:
> > As an aside, can someone explain why we reread the lock holder:
> >
> >         lwsync                          # if odd, give up cycles\n\
> >         ldx             %1,0,%2         # reverify the lock holder\n\
> >         cmpd            %0,%1\n\
> >         bne             1b              # new holder so restart\n\
> >
> > Wont there be a race regardless of whether this code is there?
> It is a tricky case, but the sequence is required.  Here is the situation:
> Proc A holds the lock
> Proc B sees proc A as the holder, then gets preempted
> Proc A drops the lock, then cedes for a long time
> Proc B reads proc A's yield count, which is valid (odd)
> Proc B confers to proc A, but does not wake up until after A is dispatched.
> The lwsync + reread ensures this cannot occur.

Uhh, can someone copy these comments into the code, for future reference?

Over the last year, I've fixed several locking/race bugs that
involved some subtle assumptions.

-- linas

speaking of subtle assumptions:  why do HMT_LOW, HMT_MED need to
be no-ops? Why just make them be nothing at all?

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/

More information about the Linuxppc64-dev mailing list