[Linuxsampler-devel] Re: [ardour-dev] atomic.h

[Christian S. <chr...@ep...>]

Es geschah am Montag, 5. Januar 2004 18:16 als Jack O'Quin schrieb:
> Christian Schoenebeck <chr...@ep...> writes:
> > Es geschah am Donnerstag, 1. Januar 2004 03:55 als Jack O'Quin schrieb:
> > > As for <atomic.h>, I don't know for certain that there are problems,
> > > but I suspect that some of JACK's shared memory updates implicitly
> > > depend on "strong ordering" of storage operations, which AFAIK is
> > > guaranteed on existing x86 implementations, but certainly is not on
> > > some other platforms (like PowerPC SMP, for example).  I can't supply
> > > any details, because this is just a suspicion.  If I knew about a
> > > definite bug, I'd fix it, or at least document it.
> >
> > atomicity.h is not an alternative for you at the moment, because
> > there is no atomic_set() equivalent in atomicity.h which is needed
> > for your ringbuffer.h
>
> Is this a guess?  Do you know of a specific problem with ringbuffer.h?

Hmmm, as you mention it, so far I thought Sparc SMP systems would lack 
atomicity while accessing 32 Bit words, but now looking at the respective 
part in atomic.h, where they use a spin lock byte in the data word itself, it 
seems that this lock byte is only needed if you're using atomic_set() and 
atomic_read() together with other atomic functions and as in rinbuffer.h only 
atomic_set() and atomic_read() are used, it seems you're right, that on 
normal GNU systems this is not needed (still only in regard to ringbuffer.h).

Benno: so it seems we could really drop atomic.h in LS or have I disregarded 
something?

CU
Christian