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
_______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
