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

[Richard Shann]

Thanks very much for these helpful observations... I hadn't grokked the
caching possibility for the memory accesses.
Richard
On Fri, 2012-02-17 at 02:12 +0100, Dominic Sacré wrote:
> 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