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
|
