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
