In my local version of the head branch, I have factored out the
spinlock declarations and definitions from csound.h into a new
csound_spinlock.h file, which is also #included in csdl.h.

This has been done so that opcodes can use the Csound spinlocks to
protect against potential data races. I have tested the code with the
Fluid opcodes and it seems to work.

The basic idea is that each opcode, or set of related opcodes, will
define one spinlock for each instance of Csound and each potential
data race (e.g., writing to and reading from the same variable or
buffer). Then, each opcode SUBR will use that spinlock to synchronize
access to the potential data race.

What I would like to do is check this change into the head branch and
merge it with the ParCS branch as well, if the other developers agree.

Regards,
Mike

-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

If I don't hear from anyone about this, I will just assume it's OK and
go ahead and do it.

Regards,
Mike

On Sat, Sep 4, 2010 at 3:33 PM, Michael Gogins  wrote:
> In my local version of the head branch, I have factored out the
> spinlock declarations and definitions from csound.h into a new
> csound_spinlock.h file, which is also #included in csdl.h.
>
> This has been done so that opcodes can use the Csound spinlocks to
> protect against potential data races. I have tested the code with the
> Fluid opcodes and it seems to work.
>
> The basic idea is that each opcode, or set of related opcodes, will
> define one spinlock for each instance of Csound and each potential
> data race (e.g., writing to and reading from the same variable or
> buffer). Then, each opcode SUBR will use that spinlock to synchronize
> access to the potential data race.
>
> What I would like to do is check this change into the head branch and
> merge it with the ParCS branch as well, if the other developers agree.
>
> Regards,
> Mike
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Not sure I understand what you are suggesting.  Not every opcode needs
a spinlock so it seems wasteful to add one always.  Not sure th epoint
of a separate csound_spinlock.h file either
==John ffitch

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Of course, not every opcode will get a spinlock. Only the ones with
potential data races. Examples would be the busses, mixer, signal flow
graph, ftable, fluid synth opcodes where there are common buffers or
data structures that can be read from and written to by simultaneous
threads.

The need for a separate csound_spinlock.h is because opcodes can't
#include csound.h where the spinlocks are defined if they #include
csdl.h, as they are supposed to. Therefore, both csound.h and csdl.h
#include csound_spinlock.h. There are no functions in
csound_spinlock.h that take a CSOUND struct pointer.

The existing spinlocks are in the CSOUND struct. This will not work
with plugin opcodes, they need to maintain their own spinlocks mapped
to instances of Csound.

I would like to get moving with this. I think the ParCS stuff is great
and the next release of Csound should have the new parser and the
ParCS code.

So that you can see what I am talking about, I have attached the files
to this email.

Regards,
Mike

On Sun, Sep 5, 2010 at 11:37 AM, john ffitch  wrote:
> Not sure I understand what you are suggesting.  Not every opcode needs
> a spinlock so it seems wasteful to add one always.  Not sure th epoint
> of a separate csound_spinlock.h file either
> ==John ffitch
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

There is another solution. I have tested OpenMP critical sections
against Csound's spinlocks and the OpenMP critical sections are a bit
faster (probably not really a significant difference), work fine, and
are simpler to code with. I would prefer the OpenMP critical sections
so I will withdraw my suggestion about csound_spinlock.h, unless other
developers would prefer the option of using Csound spinlocks in
opcodes.

Regards,
Mike

On Sat, Sep 4, 2010 at 3:33 PM, Michael Gogins  wrote:
> In my local version of the head branch, I have factored out the
> spinlock declarations and definitions from csound.h into a new
> csound_spinlock.h file, which is also #included in csdl.h.
>
> This has been done so that opcodes can use the Csound spinlocks to
> protect against potential data races. I have tested the code with the
> Fluid opcodes and it seems to work.
>
> The basic idea is that each opcode, or set of related opcodes, will
> define one spinlock for each instance of Csound and each potential
> data race (e.g., writing to and reading from the same variable or
> buffer). Then, each opcode SUBR will use that spinlock to synchronize
> access to the potential data race.
>
> What I would like to do is check this change into the head branch and
> merge it with the ParCS branch as well, if the other developers agree.
>
> Regards,
> Mike
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net