This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [PATCH] correction for PPC __compare_and_swap

> From:
> Date: Fri, 4 May 2001 14:59:00 +0100

> This patch corrects an error in PPC __compare_and_swap.
> An isync is necessary after acquisition of a lock to discard all prefetched
> instructions.  On page 335 of the The PowerPC Architecture:  A
> Specification For A New Family Of RISC Processors book it states the
> following:  The "sync" instruction is execution synchronizing.  It is not
> context synchronizing, and therefore need not discard prefetched
> instructions.  For context synchronization you can see page 371 where the
> following instructions rfi, sc and isync can be used.   End of quote.
> What can happen is the processor could speculative load values into
> registers as it is acquiring the lock and there is an opportunity to have
> fetched stale data because another processor still owns the lock and is
> modifying data that is protected by the lock. 

The Programming Environments Manual says that 'Executing a sync
instruction ensures that all instructions previously initiated appear
to have completed before any subsequent instructions are initiated.'

It's true that the processor can prefetch _instructions_ before a sync
and execute them afterwards, but any memory operations that those
instructions perform must appear to be executed after any memory
operations before the sync, otherwise the processor is not PowerPC

> The processor that is trying to acquire the lock has speculatively
> loaded the data the other processor is modifying.  The processor
> finally succeeds in acquiring the lock and continues on with the
> data it had already loaded.  The sync at the end does not cause the
> prefetched data to be discarded.  The isync causes all the
> speculative execution to be thrown away and re-executed.

I'm not sure if the sync should cause the prefetched data to be
discarded (unless there was other bus traffic), but the bus broadcast
of the other processor (the one releasing the lock) caused by the sync
before it releases certainly should.

Are you experiencing real problems, or is all this from code inspection?

- Geoffrey Keating <>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]