[Mono-devel-list] more ppc atomic.h cleanups

[David Waite]

I actually do not know which of the Interlocked* API calls are
expected to have this behavior, so I did not add it. In particular, I
know the InterlockedCompareExchange call has a memory barrier semantic
on x86, but that behavior does not seem to be defined for any other
platform.

- David Waite

On 4/14/05, Eyal Alaluf <eyala at mainsoft.com> wrote:
> Hi, all.
> 
> Shouldn't the interlocked API's implementation use sync & isync for the memory
> barriers?
> At least in C++, we have seen many cases where people implemented their own
> mutexes using interlocked APIs. Now on multiple CPU system and PPC in
> particular a mutex needs to flush the memory barriers so two diferent threads
> sharing the same data will be synchronized if they use the mutex properly.
> 
> Eyal.
> 
> On Wed, 13 Apr 2005, David Waite wrote:
> 
> > Date: Wed, 13 Apr 2005 12:31:50 -0600
> > From: David Waite <dwaite at gmail.com>
> > To: Mono Development List <mono-devel-list at lists.ximian.com>
> > Subject: [Mono-devel-list] more ppc atomic.h cleanups
> >
> > Attached is a patch that performs cleanups of atomic.h for the ppc architecture:
> >
> > * InterlockedIncrement, InterlockedDecrement: use one fewer register,
> > avoid initialization and remove extra addition/subtraction at the end
> > * InterlockedExchange: remove tmp initialization, rename tmp to result
> > to be consistant with other methods
> >
> > -David Waite
> >
> 
> 
>