[LAD] Best practice for sharing complex data structures with a jack callback function

Arnold Krille arnold at arnoldarts.de
Sat Jul 7 10:25:18 UTC 2007


Am Samstag, 7. Juli 2007 schrieb Lars Luthman:
> On Sat, 2007-07-07 at 12:03 +0200, Arnold Krille wrote:
> > Am Samstag, 7. Juli 2007 schrieb Lars Luthman:
> > > On Sat, 2007-07-07 at 02:34 +0200, Fons Adriaensen wrote:
> > > > * The callback has to know when it can (re)write the object.
> > > >   Clearly it should never wait on a sema, and it is already
> > > >   periodic, so here you can use a flag in the object.
> > > Is there any advantage in using a simple flag instead of a semaphore
> > > and sem_trywait()?
> > A semaphore might mislead you to use wait()/lock() in the wrong thread...
> Seriously now, I'm not _that_ stupid. =)

Yeah, me too. And we will remember that next time we search for some crazy 
bug, hard to reproduce, bailing out on jack... and than we realize that 
people make errors...

> > And if you only sync two threads and each of them has its own flag (for
> > write), there shouldn't be any race-conditions and its easier to use a
> > bool-variable than semaphore->bla().
> I guess so. Can you always be sure that writing to word-sized variables
> is atomic on SMP systems?

Well, a flag is either in a bit-field, which I don't recommend, or a bool 
variable which should be a char on most (all?) systems. Or you can force that 
by using the type char. And that should be atomic.

> Although if you only check for 0 or not 0 I guess it doesn't matter.

Right. One thread only writes true or false to that variable and the other one 
just reads...

Arnold
-- 
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me 
to all your contacts.
After a month or so log in as root and do a rm / -rf. Or ask your 
administrator to do so...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20070707/d4527fa0/attachment.pgp>


More information about the Linux-audio-dev mailing list