This is the mail archive of the libc-alpha@sources.redhat.com 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]
Other format: [Raw text]

Re: [PATCH] PPC atomic.h add compare_exchange_val forms


Steve,

> > To be completely safe on ppc should all atomic types actually fill
> > the entire cache line size of the cpu to prevent two separate atomic 
> > types from falling into the same cache line.
> >
> > If two threads ever compete for them neither may ever get the 
> > reservation clearly without the other one clearing it first and we 
> > could end up with some sort of strange live-lock situation?
> 
> As stated in my previous response there is a danger of "Live Lock" when 
> multiple locks share a "reservation unit" (for example a cache line). 

Do the threads make _any_ progress?

Is it only in the SMP case where the CPU's can try to steal ownership 
of the cacheline from the cache-controller and live-lock?

> So it is a good idea to avoid arrays of locks. But including a single lock 
> as a field in a larger structure is usually OK. Padding locks out to cache 
> line size is problematic since you don't know the cache line size at 
> compile time.

I've struggled with this idea for HPPA since the architecture reference
explicitly states that only a single lock word is allowed on the cacheline
(stride is 64-128 bytes wide depending on the processor).

Padding to cacheline size was attempted, but static locks would have to
pad to maximum cacheline size. This seemed to be wasteful and problematic 
for backwards binary compatibility, it also gave the linker some headaches.

Do you just live with the fact that two locks _could_ reside on the same
cacheline?

c.


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