Subject: Re: [linux-audio-dev] shared memory synchronization
From: est_AT_hyperreal.org
Date: to syys 30 1999 - 19:42:51 EDT
Bill Gribble discourseth:
> est_AT_hyperreal.org writes:
> > 1) Correct volatile declarations are important. It would be nice if C
> > guaranteed that these aren't needed if you have function calls between
> > uses of a pointer, but that doesn't seem to be the case. BTW, on the
> > other end of the aliasing spectrum, c9x has a `restrict' type
> > qualifier that allows the programmer to provide guarantees against
> > aliasing.
> >
> > 2) Multiprocessor cache synchronization. POSIX guarantees that
> > certain operations (e.g., pthread_mutex_lock()) will cause this to
> > occur. Do they under linux? Does the lock/cmpxchgl operation used
> > by linuxthreads, for example, cause this to happen? This is very
> > important to me as I'm working on SMP-friendly approaches to garbage
> > collection and problems here will cause more than imperceptible audio
> > glitches.
>
> My understanding is that these two are an either/or proposition
> in most cases. If you faithfully use mutex synchronization of
> shared variables, volatile is always superfluous (and can be a major
> performance hit).
Hmm..I can't see how that would be the case. volatile stops the
compiler from optimizing away dereferences (e.g., via
loop-invariant-code-motion). It could be that your mutex ops are
out-of-line and thus have the same effect, but I can't see that there
are any guarantees that that will always be the case.
> If someone knows better, please let me know... i have tens of KLOC
> of multithreaded real-time vision code that depends on my understanding
> being correct :)
Maybe you could display a code fragment illustrating this?
Eric
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST