Steven Yi wrote code, which I also worked on, that permits N threads to simultaneously execute instrument instances. This code is in CVS and has been tested a little bit. We have proved that it does make Csound somewhat more efficient. Now we want to make this code actually usable. The first step is to protect the audio input and output buffers.

Typically, instrument instances write to the same output, the spout buffer. The spinlocks are to protect spout and spin from simultaneous accesses. The situation we are dealing with is as follows:

Thread 1 begins to send a 4 byte float to spout. This means _adding_ that float to one slot in spout, e.g. with outs. So, outs is halfway through adding its float to spout in thread 1... adding floating-point numbers is not an atomic operation!...

...The operating system pre-empts thread 1 and puts it to sleep before it has finished adding.

Thread 2 now begins to send its own 4 byte float to spout. outs adds 4 bytes to spout. Depending on what happens in the addition operation (which bytes have 1 bits, whether there is an exponent, etc.) spout is now inconsistent.

Thread 1 wakes up, and finishes adding its final 2 bytes to spout. Spout is still inconsistent. The spout buffer remains inconsistent until the next kperiod.

Now all threads have completed their instrument instances, and the thread barrier is released. Csound's main thread resumes and sends an inconsistent spout to the audio output driver... CLICK. 

This conflict, I admit, should be rare. It would require (a) the two threads to be adding to spout at the same time (already rare), (b) the two to be adding to the SAME FRAME of spout at the same time (even more rare), (c) one thread to be interrupted while adding, and (d) the addition operation to be affected by the interruption (e.g. the two samples have different exponents). But at N threads x 88200 frames per second x N channels x 4 or 8 bytes per second for 10 minutes (say), it WILL happen.

Using a spinlock just means that, in this scenario, thread 2 has to wait for thread 1 to wake up and finish adding its sample to spout before thread 2 can add its sample. 
The change that I made on your request means that all of the out family of opcodes share one spinlock, and all of the in family share one spinlock; previously (for example) outq was protected against another thread's outq, but not against another thread's outs.

This is very basic stuff we are doing here, fortunately, because apparently this kind of thing gets tricky fast.

The overhead of calling the spinlock functions is practically nothing, certainly much less than mutexes. The overhead of one thread waiting for another thread to finish something would be the same in most synchronization schemes.

Regards,
Mike


-----Original Message-----
>From: jpff 
>Sent: Sep 9, 2008 11:54 AM
>To: Michael Gogins , Developer discussions 
>Cc: csound-devel@lists.sourceforge.net
>Subject: Re: [Cs-dev] Spinlocks
>
>If someone writes to the input while opcodes are reading it then there
>is something very wrong with the semantics!  In Csound if reading of
>input is not thread-safe then the system is bust.  You need it for
>channels and zak of course but not in
>==John ffitch
>
>Apologies for delay -- my firewall disk collapsed at 4:30am and I have
>spent the day rebuilding on a machine without CD or floppy.....
>
>-------------------------------------------------------------------------
>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>Build the coolest Linux based applications with Moblin SDK & win great prizes
>Grand prize is a trip for two to an Open Source event anywhere in the world
>http://moblin-contest.org/redirect.php?banner_id=100&url=/
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net