[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Denemo-devel] Real time playback in Denemo
From: |
Dominic Sacré |
Subject: |
Re: [Denemo-devel] Real time playback in Denemo |
Date: |
Fri, 17 Feb 2012 02:12:32 +0100 |
User-agent: |
KMail/1.13.5 (Linux/2.6.32-38-generic; KDE/4.4.5; i686; ; ) |
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
- Re: [Denemo-devel] Real time playback in Denemo,
Dominic Sacré <=