25 Aug
2013
25 Aug
'13
12:11 a.m.
Hi all,
I just joined the developers list as I've been looking into adding
Jack midi support to one of my favourite sequencers (harmonySEQ) and
need some advice related to threading and shared data. I know these
issues have come up before, specifically I found two related threads
[1][2], but I am still confused as to what would be the best approach.
(I am also new to thread programming in general.)
As this is a sequencer the main data structure is a list of patterns
where each pattern contains a list of notes. Patterns can be
manipulated while being played back. Both the GUI thread and Jack
thread should be able to modify the patterns, e.g. a midi event might
toggle a pattern on/off, the GUI can insert a note into a pattern, or
add or remove a pattern.
I've considered different approaches (separate data for each thread,
various versions of shared data), but I believe all of them make at
least two assumptions: That reading and writing byte-sized data (e.g.
a bool flag) and that updating pointers is atomic. I got a bit
confused reading this thread [2]. Are these assumptions correct?
To be more specific, one of the schemes I came up with followed the
idea of using only one shared data structure which has to be in a
consistent state at all points in time. To ensure this I would have to
be very careful as to how I update the data structure. For example, if
the GUI added or removed a note from a pattern (which might involve a
memory reallocation) it would do so by performing theses changes on a
copy of the current pattern and then replace the original pattern by
updating the pointer to this new version of the pattern. Simple
updates (e.g. turning a pattern on / off) would be performed directly
on the pattern as I consider them atomic. To keep references to
patterns throughout the code I would use some global registry, as I
cannot use pointers for they "expire" (might point to an old version
of the pattern).
Does that make sense? Are there some obvious flaws with that scheme
that I oversaw, are there better ways to go about it? I am really
quite new to this kind of programming issues, I would appreciate any
pointers and advice!
Thanks,
Burkhard
[1]
http://linux-audio.4202.n7.nabble.com/Best-practice-for-sharing-complex-dat…
[2] http://linux-audio.4202.n7.nabble.com/Atomic-Operations-td58961.html
27 Aug
27 Aug
7:53 p.m.
[Burkhard Ritter]
I've considered different approaches (separate data
for each thread,
various versions of shared data), but I believe all of them make at
least two assumptions: That reading and writing byte-sized data (e.g.
a bool flag) and that updating pointers is atomic. I got a bit
confused reading this thread [2]. Are these assumptions correct?
It's been a while since I did some research: IIrc on i386, 32-bit read
or write access is atomic if the variable address is 32-bit aligned,
while on ARM only byte-size read and write operations are atomic,
regardless of alignment. (On a sidenote, it is not realistic to
expect gcc to honour alignment instructions.)
However, you're probably well-advised not to take my word on it. You
better research this thoroughly yourself before designing your
multithreaded architecture around it. You might go weeks before
encountering a problem, and then you might spend a week trying to hunt
it down as these things are often very difficult to recreate and
isolate, and then you might discover your basic assumptions were
wrong.
For passing data between threads locklessly in a deterministic manner,
I'd recommend a FIFO, which you can build with byte-sized counters.
Hope this helps,
Tim
17 Sep
17 Sep
2:34 a.m.
Hi Tim,
thanks, that was very helpful. Unfortunately, I am only now finally
getting back to looking into this again.
On Tue, Aug 27, 2013 at 11:50 AM, Tim Goetze <tim(a)quitte.de> wrote:
It's been a while since I did some research: IIrc
on i386, 32-bit read
or write access is atomic if the variable address is 32-bit aligned,
while on ARM only byte-size read and write operations are atomic,
regardless of alignment. (On a sidenote, it is not realistic to
expect gcc to honour alignment instructions.)
I take from this that it's generally not safe to assume that any read
or write operation is atomic, because I can't reliably control
alignment. Indeed, this is the general impression I get from reading
and searching on the web (mostly StackOverflow).
I stumbled upon this superb talk by Herb Sutter [1], which really made
things a lot clearer to me. My understanding now is that: 1. Atomicity
(meaning atomic read and write) in and by itself is not enough. I also
need to ensure that memory access does not get reordered across my
atomic reads and writes (so that, for example, I don't happen to
increase the write counter before the data is actually written to the
buffer). 2. To ensure atomicity and to enforce these memory barriers I
always need some (cpu/architecture specific) special instructions.
It looks like C++11 actually now has support for atomic operations
which fulfill the above two points, so I'll likely try to go down that
route. Does anybody have experience with the new C++ atomic header?
For passing data between threads locklessly in a
deterministic manner,
I'd recommend a FIFO, which you can build with byte-sized counters.
I am using two queues, one to pass messages from the gui to the
engine, and one the other way around. Still, for largish data
structures it does not seem practical to copy them back and forth
between the threads so I need to be careful how I update these data
structures.
Cheers,
Burkhard
[1]
http://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Herb-Sutter-a…
10:25 a.m.
On Mon, 16 Sep 2013 18:34:17 -0600
Burkhard Ritter <burkhard(a)ualberta.ca> wrote:
My understanding now is that: 1. Atomicity
(meaning atomic read and write) in and by itself is not enough. I also
need to ensure that memory access does not get reordered across my
atomic reads and writes (so that, for example, I don't happen to
increase the write counter before the data is actually written to the
buffer). 2. To ensure atomicity and to enforce these memory barriers I
always need some (cpu/architecture specific) special instructions.
Hi,
For atomic read/writes, barriers, and other atomic operations,
cpu-specific instructions are not needed anymore. You can use generic
gcc builtins:
http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Atomic-Builtins.html
-Alexandre.
8:34 p.m.
On Tue, Sep 17, 2013 at 2:25 AM, Alexandre DENIS
<contact(a)alexandredenis.net> wrote:
For atomic read/writes, barriers, and other atomic
operations,
cpu-specific instructions are not needed anymore. You can use generic
gcc builtins:
http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Atomic-Builtins.html
-Alexandre.
Hi Alexandre,
what I meant was that somewhere along the compiler chain cpu-specific
instructions need to be generated. I think glib provides the
functionality. I didn't know about the GCC builtins you mention, but
it looks to me like they are superseded by C++11's atomic types [1].
When I originally started looking into atomicity I thought it would be
enough to use a (architecture specific) data type size which would be
written and read atomically. However, that's not correct. (Also,
initially I wasn't aware I need some sort of memory barrier.)
Cheers,
Burkhard
[1] http://www.cplusplus.com/reference/atomic/atomic/
3867
days inactive
3891
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
Alexandre DENIS -
Burkhard Ritter -
Tim Goetze