This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [PATCH] PPC atomic.h add compare_exchange_val forms
- From: "Kevin B. Hendricks" <kevin dot hendricks at sympatico dot ca>
- To: "Steve Munroe" <sjmunroe at us dot ibm dot com>
- Cc: libc-alpha <libc-alpha at sources dot redhat dot com>
- Date: Tue, 15 Apr 2003 14:22:10 -0400
- Subject: Re: [PATCH] PPC atomic.h add compare_exchange_val forms
- References: <OF5DAD2E7C.FCE0C7B3-ON86256D09.005B9C41-86256D09.0063598A@rchland.ibm.com>
Hi,
Thanks for the Info.
Kevin
On April 15, 2003 02:05 pm, Steve Munroe wrote:
> Kevin Hendricks writes:
>
> > But do we need to worry about a lwarx. and ldarx. setting reservations
> > bits (on cache lines representing addresses) that never see paired a
> > stdcx. or a stwcx. to clear them when the jump happens?
>
> Not a problem, the reservation is reset by the next lwarx/ldarx.
>
> > Also do we need to worry about alignment of a 64 bit value in the 32
> > byte cache line to prevent layouts that might end up having 4 of the
> > bytes in one cache line and the next four in another cache line making
> > the reservation idea not work properly?
>
> The effective address of lwarx/ldarx/stwcx/stdcx must be
(word/doubleword)
> aligned.
>
> From "The PowerPC Architecture" page 77 ... "If it is not, either the
> system alignement handler is invoked or the results are boundedly
> undefined."
>
> In most PowerPC implementations the reservation is actually on the cache
> line. This has several implications:
>
> 1) The lock would not work atomically if the lock word spanned cache
> lines.
> 2) Packing multiple lock words into a single cache line can result in
> "live lock" between threads sharing the cache line.
> 3) The cache line size varies across implementations. Current PowerPC64
> implementations use a 128 byte line. So a PPC32 application may see
> difference cache line sizes depending on if it is running on PowerPC32 or
> PowerPC64 hardware.
>
>