Re: [Denemo-devel] Real time playback in Denemo

[Dominic Sacré]

On Sunday 01 January 2012 19:13:30 Richard Shann wrote:
> The g_cond_timed_wait() unlocks the mutex before the thread sleeps
> and locks it when it continues.
> ***Question*** is it ok that the mutex has not been locked for the
> first time (and correspondingly, at the end g_mutex_free() is called
> without unlocking the mutex, is that ok?).

Oops, the mutex should in fact be locked, right after creating it, and 
it should be unlocked before destoying it. This mutex doesn't really do 
much anyway, but currently it's undefined behaviour and it should be 
fixed.
 
> Next a check is made for quitting the loop - this is done by making
> an atomic access to an int which is set by the alsa_seq_destroy()
> call. ***Question*** does that need to be an atomic access? The int
> in question is just a boolean, so in C it just means that if any of
> the bits are set it is true. So it really doesn't matter if another
> thread is halfway through setting it.

The g_atomic_* operations are not just to ensure that variables aren't 
accessed while being written to by another thread. They also make sure 
that required memory barriers are in place, so, simply put, the threads 
don't read "old" data.
For example, on some architectures two threads may be running on 
different CPU cores, each of which might have its own cache of the main 
memory. Without memory barriers, the variables might change without 
other threads ever noticing...

In practice, at least on x86, this is not really an issue, but threading 
bugs are notoriously unpredictable and hard to reproduce, so it's better 
to play safe.


Dominic