11 Jul
2011
11 Jul
'11
10:44 p.m.
On Mon, Jul 11, 2011 at 03:02:57PM +0300, Dan Muresan wrote:
Well, if you are content with any old possible value
of xval (i.e. you
have no synchronization on it anywhere), you are right; but then you
might as well make xval a constant -- just use the first value it ever
had. You have no guarantees that the thread calling f() will EVER have
its hardware cache synchronized to whoever is producing xval. Cache
coherency again...
The typical use case would be xval being some parameter used
by e.g. a Jack callback and updated by e.g. MIDI events, or
a measurement; and f() being the code that runs periodically
to update the GUI element for that parameter or measurement.
There is no synchronisation and occasionally using an out-
dated value has no fatal consequences - it will very probably
be put right on the next update which is 1/10 second or so
in the future. The display is informative only, correct audio
processing does in no way depend on it being up to date.
Otherwise, I bet you *do* have some synchronization,
somewhere, for
xval in the thread that calls f. Wherever that place is, save the
cached value, i.e.
mutex_lock()
x = xval
mutex_unlock()
f (x)
That would mean the other side has to use the mutex as well
when updating xval, and in a Jack callback that is 'not done',
at least not if the mutex could be held by a non-realtime
thread such as one updating the GUI.
In the signal case, you should of course make sure the
signal is
caught by the thread who reads x, by using pthread_sigmask()
appropriately. Or make the program non-threaded. Otherwise, you now
have two problems...
Not if there is no synchronisation involved as in the example
above. If all the signal handler has to do is update xval, it
doesn't matter in which thread it runs.
Also, strictly speaking if you're using a
sighandler plus volatile,
you should also declare xval as sig_atomic_t.
Strictly true, but R/W of ints is atomic on the platforms that
matter to me.
Ciao,
--
FA