Spinlocks

[Felipe Sateler]

I have received a report that csound does not build on SPARC machines due to
some issues with __sync_* intrinsics. While I am still trying to debug the
issue, the question of why these intrinsics were used in the first place was
raised. In fact, we already use pthread, and pthread provides spinlocks too.
Is there any reason for not using the pthread ones?

Saludos,
Felipe Sateler


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Michael Gogins-2]

Insofar as I recall, which may not be all that far, the pthread
spinlocks were not available on all platforms.

if they are, they would be better, I think.

Regards,
Mike

On 4/29/09, Felipe Sateler <fsateler@...> wrote:
> I have received a report that csound does not build on SPARC machines due to
> some issues with __sync_* intrinsics. While I am still trying to debug the
> issue, the question of why these intrinsics were used in the first place was
> raised. In fact, we already use pthread, and pthread provides spinlocks too.
> Is there any reason for not using the pthread ones?
>
> Saludos,
> Felipe Sateler
>


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

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Felipe Sateler]

Pthreads-w32 (which is what I think you are using on windows) claims to
support it. Can someone from the mac world confirm if they are available?

El 30/04/09 01:44 Michael Gogins escribió:

> Insofar as I recall, which may not be all that far, the pthread
> spinlocks were not available on all platforms.
>
> if they are, they would be better, I think.
>
> Regards,
> Mike
>
> On 4/29/09, Felipe Sateler <fsateler@...> wrote:
> > I have received a report that csound does not build on SPARC machines due
> > to some issues with __sync_* intrinsics. While I am still trying to debug
> > the issue, the question of why these intrinsics were used in the first
> > place was raised. In fact, we already use pthread, and pthread provides
> > spinlocks too. Is there any reason for not using the pthread ones?
> >
> > Saludos,
> > Felipe Sateler

Saludos,
Felipe Sateler


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Felipe Sateler]

I am trying to implement the spinlocks with pthreads. However, multithreading
does not work for me, there seems to be a race condition somewhere, since it
hangs if I run it normally, but not if I run it under gdb. Valgrind says the
following:

==24848== Possible data race during write of size 8 at 0x90560c8 by thread #1
==24848==    at 0x40B481: kperf (csound.c:1320)
==24848==    by 0x40B8B1: csoundPerform (csound.c:1447)
==24848==    by 0x40550E: main (csound_main.c:136)
==24848==  This conflicts with a previous read of size 8 by thread #3
==24848==    at 0x40AF5D: kperfThread (csound.c:1226)
==24848==    by 0x4C27ABF: mythread_wrapper (hg_intercepts.c:194)
==24848==    by 0x5092FA9: start_thread (in /lib/libpthread-2.9.so)
==24848==    by 0x61C42CC: clone (in /lib/libc-2.9.so)


I'm not sure if this is relevant, it is the multiThreadedStart variable that
conflicts. Maybe the reads and writes of it should be protected?

El 30/04/09 10:22 Felipe Sateler escribió:

> Pthreads-w32 (which is what I think you are using on windows) claims to
> support it. Can someone from the mac world confirm if they are available?
>
> El 30/04/09 01:44 Michael Gogins escribió:
> > Insofar as I recall, which may not be all that far, the pthread
> > spinlocks were not available on all platforms.
> >
> > if they are, they would be better, I think.
> >
> > Regards,
> > Mike
> >
> > On 4/29/09, Felipe Sateler <fsateler@...> wrote:
> > > I have received a report that csound does not build on SPARC machines
> > > due to some issues with __sync_* intrinsics. While I am still trying to
> > > debug the issue, the question of why these intrinsics were used in the
> > > first place was raised. In fact, we already use pthread, and pthread
> > > provides spinlocks too. Is there any reason for not using the pthread
> > > ones?
> > >
> > > Saludos,
> > > Felipe Sateler
>
> Saludos,
> Felipe Sateler

Saludos,
Felipe Sateler


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Felipe Sateler]

Attached is what I get if I run multithreaded "./csound -v --num-threads=2
examples/trapped.csd".

El 30/04/09 20:53 Felipe Sateler escribió:

> I am trying to implement the spinlocks with pthreads. However,
> multithreading does not work for me, there seems to be a race condition
> somewhere, since it hangs if I run it normally, but not if I run it under
> gdb. Valgrind says the following:
>
> ==24848== Possible data race during write of size 8 at 0x90560c8 by thread
> #1 ==24848==    at 0x40B481: kperf (csound.c:1320)
> ==24848==    by 0x40B8B1: csoundPerform (csound.c:1447)
> ==24848==    by 0x40550E: main (csound_main.c:136)
> ==24848==  This conflicts with a previous read of size 8 by thread #3
> ==24848==    at 0x40AF5D: kperfThread (csound.c:1226)
> ==24848==    by 0x4C27ABF: mythread_wrapper (hg_intercepts.c:194)
> ==24848==    by 0x5092FA9: start_thread (in /lib/libpthread-2.9.so)
> ==24848==    by 0x61C42CC: clone (in /lib/libc-2.9.so)
>
>
> I'm not sure if this is relevant, it is the multiThreadedStart variable
> that conflicts. Maybe the reads and writes of it should be protected?
>
> El 30/04/09 10:22 Felipe Sateler escribió:
> > Pthreads-w32 (which is what I think you are using on windows) claims to
> > support it. Can someone from the mac world confirm if they are available?
> >
> > El 30/04/09 01:44 Michael Gogins escribió:
> > > Insofar as I recall, which may not be all that far, the pthread
> > > spinlocks were not available on all platforms.
> > >
> > > if they are, they would be better, I think.
> > >
> > > Regards,
> > > Mike
> > >
> > > On 4/29/09, Felipe Sateler <fsateler@...> wrote:
> > > > I have received a report that csound does not build on SPARC machines
> > > > due to some issues with __sync_* intrinsics. While I am still trying
> > > > to debug the issue, the question of why these intrinsics were used in
> > > > the first place was raised. In fact, we already use pthread, and
> > > > pthread provides spinlocks too. Is there any reason for not using the
> > > > pthread ones?
> > > >
> > > > Saludos,
> > > > Felipe Sateler
> >
> > Saludos,
> > Felipe Sateler
>
> Saludos,
> Felipe Sateler

Saludos,
Felipe Sateler



------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Victor Lazzarini]

AFAIK --num-threads > 1 is broken. I think I have mentioned this here.
The reason nothing is being done is because John ffitch has a new
multithread
implementation which will replace what is there at the moment.

Victor
----- Original Message -----
From: "Felipe Sateler" <fsateler@...>
To: "Developer discussions" <csound-devel@...>
Sent: Thursday, April 30, 2009 12:10 PM
Subject: Re: [Cs-dev] Spinlocks


Attached is what I get if I run multithreaded "./csound -v --num-threads=2
examples/trapped.csd".

El 30/04/09 20:53 Felipe Sateler escribió:

> I am trying to implement the spinlocks with pthreads. However,
> multithreading does not work for me, there seems to be a race condition
> somewhere, since it hangs if I run it normally, but not if I run it under
> gdb. Valgrind says the following:
>
> ==24848== Possible data race during write of size 8 at 0x90560c8 by thread
> #1 ==24848==    at 0x40B481: kperf (csound.c:1320)
> ==24848==    by 0x40B8B1: csoundPerform (csound.c:1447)
> ==24848==    by 0x40550E: main (csound_main.c:136)
> ==24848==  This conflicts with a previous read of size 8 by thread #3
> ==24848==    at 0x40AF5D: kperfThread (csound.c:1226)
> ==24848==    by 0x4C27ABF: mythread_wrapper (hg_intercepts.c:194)
> ==24848==    by 0x5092FA9: start_thread (in /lib/libpthread-2.9.so)
> ==24848==    by 0x61C42CC: clone (in /lib/libc-2.9.so)
>
>
> I'm not sure if this is relevant, it is the multiThreadedStart variable
> that conflicts. Maybe the reads and writes of it should be protected?
>
> El 30/04/09 10:22 Felipe Sateler escribió:
> > Pthreads-w32 (which is what I think you are using on windows) claims to
> > support it. Can someone from the mac world confirm if they are
> > available?
> >
> > El 30/04/09 01:44 Michael Gogins escribió:
> > > Insofar as I recall, which may not be all that far, the pthread
> > > spinlocks were not available on all platforms.
> > >
> > > if they are, they would be better, I think.
> > >
> > > Regards,
> > > Mike
> > >
> > > On 4/29/09, Felipe Sateler <fsateler@...> wrote:
> > > > I have received a report that csound does not build on SPARC
> > > > machines
> > > > due to some issues with __sync_* intrinsics. While I am still trying
> > > > to debug the issue, the question of why these intrinsics were used
> > > > in
> > > > the first place was raised. In fact, we already use pthread, and
> > > > pthread provides spinlocks too. Is there any reason for not using
> > > > the
> > > > pthread ones?
> > > >
> > > > Saludos,
> > > > Felipe Sateler
> >
> > Saludos,
> > Felipe Sateler
>
> Saludos,
> Felipe Sateler

Saludos,
Felipe Sateler



--------------------------------------------------------------------------------


> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf


--------------------------------------------------------------------------------


> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Steven Yi]

Hi Victor,

I'm not sure it is broken, but it does require intervention to
manually protect resources using the mutex opcodes.  This is much akin
to what developers do with programming in C, Java, etc. I'd have to
check  the problematic orc to see what could be the peoblem, but I'd
guess first thing that mutexes would be necessary.

Steven

On 4/30/09, victor <Victor.Lazzarini@...> wrote:

> AFAIK --num-threads > 1 is broken. I think I have mentioned this here.
> The reason nothing is being done is because John ffitch has a new
> multithread
> implementation which will replace what is there at the moment.
>
> Victor
> ----- Original Message -----
> From: "Felipe Sateler" <fsateler@...>
> To: "Developer discussions" <csound-devel@...>
> Sent: Thursday, April 30, 2009 12:10 PM
> Subject: Re: [Cs-dev] Spinlocks
>
>
> Attached is what I get if I run multithreaded "./csound -v --num-threads=2
> examples/trapped.csd".
>
> El 30/04/09 20:53 Felipe Sateler escribió:
>> I am trying to implement the spinlocks with pthreads. However,
>> multithreading does not work for me, there seems to be a race condition
>> somewhere, since it hangs if I run it normally, but not if I run it under
>> gdb. Valgrind says the following:
>>
>> ==24848== Possible data race during write of size 8 at 0x90560c8 by thread
>> #1 ==24848==    at 0x40B481: kperf (csound.c:1320)
>> ==24848==    by 0x40B8B1: csoundPerform (csound.c:1447)
>> ==24848==    by 0x40550E: main (csound_main.c:136)
>> ==24848==  This conflicts with a previous read of size 8 by thread #3
>> ==24848==    at 0x40AF5D: kperfThread (csound.c:1226)
>> ==24848==    by 0x4C27ABF: mythread_wrapper (hg_intercepts.c:194)
>> ==24848==    by 0x5092FA9: start_thread (in /lib/libpthread-2.9.so)
>> ==24848==    by 0x61C42CC: clone (in /lib/libc-2.9.so)
>>
>>
>> I'm not sure if this is relevant, it is the multiThreadedStart variable
>> that conflicts. Maybe the reads and writes of it should be protected?
>>
>> El 30/04/09 10:22 Felipe Sateler escribió:
>> > Pthreads-w32 (which is what I think you are using on windows) claims to
>> > support it. Can someone from the mac world confirm if they are
>> > available?
>> >
>> > El 30/04/09 01:44 Michael Gogins escribió:
>> > > Insofar as I recall, which may not be all that far, the pthread
>> > > spinlocks were not available on all platforms.
>> > >
>> > > if they are, they would be better, I think.
>> > >
>> > > Regards,
>> > > Mike
>> > >
>> > > On 4/29/09, Felipe Sateler <fsateler@...> wrote:
>> > > > I have received a report that csound does not build on SPARC
>> > > > machines
>> > > > due to some issues with __sync_* intrinsics. While I am still trying
>> > > > to debug the issue, the question of why these intrinsics were used
>> > > > in
>> > > > the first place was raised. In fact, we already use pthread, and
>> > > > pthread provides spinlocks too. Is there any reason for not using
>> > > > the
>> > > > pthread ones?
>> > > >
>> > > > Saludos,
>> > > > Felipe Sateler
>> >
>> > Saludos,
>> > Felipe Sateler
>>
>> Saludos,
>> Felipe Sateler
>
>
>
> Saludos,
> Felipe Sateler
>
>
>
> --------------------------------------------------------------------------------
>
>
>> ------------------------------------------------------------------------------
>> Register Now & Save for Velocity, the Web Performance & Operations
>> Conference from O'Reilly Media. Velocity features a full day of
>> expert-led, hands-on workshops and two days of sessions from industry
>> leaders in dedicated Performance & Operations tracks. Use code vel09scf
>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>
>
> --------------------------------------------------------------------------------
>
>
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@...
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

--
Sent from my mobile device

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Victor Lazzarini]

yes, I thought something like that would be needed at first, but then
I could not find the manual page for mutex opcode on the windows 5.10
manual.
In other words, we would need to create a new version of trapped to
test it?
Victor
----- Original Message -----
From: "Steven Yi" <stevenyi@...>
To: "Developer discussions" <csound-devel@...>
Sent: Thursday, April 30, 2009 2:01 PM
Subject: Re: [Cs-dev] Spinlocks


Hi Victor,

I'm not sure it is broken, but it does require intervention to
manually protect resources using the mutex opcodes.  This is much akin
to what developers do with programming in C, Java, etc. I'd have to
check  the problematic orc to see what could be the peoblem, but I'd
guess first thing that mutexes would be necessary.

Steven

On 4/30/09, victor <Victor.Lazzarini@...> wrote:

> AFAIK --num-threads > 1 is broken. I think I have mentioned this here.
> The reason nothing is being done is because John ffitch has a new
> multithread
> implementation which will replace what is there at the moment.
>
> Victor
> ----- Original Message -----
> From: "Felipe Sateler" <fsateler@...>
> To: "Developer discussions" <csound-devel@...>
> Sent: Thursday, April 30, 2009 12:10 PM
> Subject: Re: [Cs-dev] Spinlocks
>
>
> Attached is what I get if I run multithreaded "./csound -v --num-threads=2
> examples/trapped.csd".
>
> El 30/04/09 20:53 Felipe Sateler escribió:
>> I am trying to implement the spinlocks with pthreads. However,
>> multithreading does not work for me, there seems to be a race condition
>> somewhere, since it hangs if I run it normally, but not if I run it under
>> gdb. Valgrind says the following:
>>
>> ==24848== Possible data race during write of size 8 at 0x90560c8 by
>> thread
>> #1 ==24848==    at 0x40B481: kperf (csound.c:1320)
>> ==24848==    by 0x40B8B1: csoundPerform (csound.c:1447)
>> ==24848==    by 0x40550E: main (csound_main.c:136)
>> ==24848==  This conflicts with a previous read of size 8 by thread #3
>> ==24848==    at 0x40AF5D: kperfThread (csound.c:1226)
>> ==24848==    by 0x4C27ABF: mythread_wrapper (hg_intercepts.c:194)
>> ==24848==    by 0x5092FA9: start_thread (in /lib/libpthread-2.9.so)
>> ==24848==    by 0x61C42CC: clone (in /lib/libc-2.9.so)
>>
>>
>> I'm not sure if this is relevant, it is the multiThreadedStart variable
>> that conflicts. Maybe the reads and writes of it should be protected?
>>
>> El 30/04/09 10:22 Felipe Sateler escribió:
>> > Pthreads-w32 (which is what I think you are using on windows) claims to
>> > support it. Can someone from the mac world confirm if they are
>> > available?
>> >
>> > El 30/04/09 01:44 Michael Gogins escribió:
>> > > Insofar as I recall, which may not be all that far, the pthread
>> > > spinlocks were not available on all platforms.
>> > >
>> > > if they are, they would be better, I think.
>> > >
>> > > Regards,
>> > > Mike
>> > >
>> > > On 4/29/09, Felipe Sateler <fsateler@...> wrote:
>> > > > I have received a report that csound does not build on SPARC
>> > > > machines
>> > > > due to some issues with __sync_* intrinsics. While I am still
>> > > > trying
>> > > > to debug the issue, the question of why these intrinsics were used
>> > > > in
>> > > > the first place was raised. In fact, we already use pthread, and
>> > > > pthread provides spinlocks too. Is there any reason for not using
>> > > > the
>> > > > pthread ones?
>> > > >
>> > > > Saludos,
>> > > > Felipe Sateler
>> >
>> > Saludos,
>> > Felipe Sateler
>>
>> Saludos,
>> Felipe Sateler
>
>
>
> Saludos,
> Felipe Sateler
>
>
>
> --------------------------------------------------------------------------------
>
>
>> ------------------------------------------------------------------------------
>> Register Now & Save for Velocity, the Web Performance & Operations
>> Conference from O'Reilly Media. Velocity features a full day of
>> expert-led, hands-on workshops and two days of sessions from industry
>> leaders in dedicated Performance & Operations tracks. Use code vel09scf
>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>
>
> --------------------------------------------------------------------------------
>
>
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@...
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

--
Sent from my mobile device

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel 



------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Felipe Sateler]

Apparently these are provided by Linux, pthreads-w32 and OSX 10.4 onwards. BSD
also seems to have support for them, and I can't find anything on solaris.

However, all of this could be avoided by switching from spinlocks to mutexes.
All implementations of pthreads have to support mutexes (at least since the
UNIX98 spec). The downside of using mutexes is that it can be slower if (and
this is a big if) the thread holding the lock is still running, and will
release the lock in a very short time. All other cases are better handled
with mutexes.


El 30/04/09 01:44 Michael Gogins escribió:

> Insofar as I recall, which may not be all that far, the pthread
> spinlocks were not available on all platforms.
>
> if they are, they would be better, I think.
>
> Regards,
> Mike
>
> On 4/29/09, Felipe Sateler <fsateler@...> wrote:
> > I have received a report that csound does not build on SPARC machines due
> > to some issues with __sync_* intrinsics. While I am still trying to debug
> > the issue, the question of why these intrinsics were used in the first
> > place was raised. In fact, we already use pthread, and pthread provides
> > spinlocks too. Is there any reason for not using the pthread ones?
> >
> > Saludos,
> > Felipe Sateler

Saludos,
Felipe Sateler


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Michael Gogins-2]

Performance is indeed the motivation for these spinlocks. I am looking to
the near future where 4 or more cores are running Csound instruments on up
to dozens of threads. In that case, spinlocks seem to promise a significant
performance advantage over mutexes, especially because we would not expect
the locks to do much actual spinning. Each lock contention would be in cache
and involve a short loop and some CAS, rather than hopping out to the OS.

Regards,
Mike

----- Original Message -----
From: "Felipe Sateler" <fsateler@...>
To: "Developer discussions" <csound-devel@...>
Sent: Friday, May 01, 2009 12:05 AM
Subject: Re: [Cs-dev] Spinlocks


> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf


--------------------------------------------------------------------------------


> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Felipe Sateler]

Perhaps we could use mutexes as a start and then optionally change them to
spinlocks when supported. Since using either is very similar in pthreads
implementation, we can switch them to test if spinlocks are effectively faster.

El viernes 1 de mayo, michael.gogins@... escribió:

> Performance is indeed the motivation for these spinlocks. I am looking to
> the near future where 4 or more cores are running Csound instruments on up
> to dozens of threads. In that case, spinlocks seem to promise a significant
> performance advantage over mutexes, especially because we would not expect
> the locks to do much actual spinning. Each lock contention would be in
> cache and involve a short loop and some CAS, rather than hopping out to the
> OS.
>
> Regards,
> Mike
>
> ----- Original Message -----
> From: "Felipe Sateler" <fsateler@...>
> To: "Developer discussions" <csound-devel@...>
> Sent: Friday, May 01, 2009 12:05 AM
> Subject: Re: [Cs-dev] Spinlocks
>
> > -------------------------------------------------------------------------
> >----- Register Now & Save for Velocity, the Web Performance & Operations
> > Conference from O'Reilly Media. Velocity features a full day of
> > expert-led, hands-on workshops and two days of sessions from industry
> > leaders in dedicated Performance & Operations tracks. Use code vel09scf
> > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>
> ---------------------------------------------------------------------------
>-----
>
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@...
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ---------------------------------------------------------------------------
>--- Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[jpff-2]

Indeed.  Talking it over with local experts I had concluded that we should
use mutexes until and unless we have a need for spinlocks.  I was going to
attemot that change when time allowed.  Feel free......
=John ff

> Perhaps we could use mutexes as a start and then optionally change them to
> spinlocks when supported. Since using either is very similar in pthreads
> implementation, we can switch them to test if spinlocks are effectively
> faster.
>
> El viernes 1 de mayo, michael.gogins@... escribió:
>> Performance is indeed the motivation for these spinlocks. I am looking
>> to
>> the near future where 4 or more cores are running Csound instruments on
>> up
>> to dozens of threads. In that case, spinlocks seem to promise a
>> significant
>> performance advantage over mutexes, especially because we would not
>> expect
>> the locks to do much actual spinning. Each lock contention would be in
>> cache and involve a short loop and some CAS, rather than hopping out to
>> the
>> OS.
>>
>> Regards,
>> Mike
>>
>> ----- Original Message -----
>> From: "Felipe Sateler" <fsateler@...>
>> To: "Developer discussions" <csound-devel@...>
>> Sent: Friday, May 01, 2009 12:05 AM
>> Subject: Re: [Cs-dev] Spinlocks
>>
>> > -------------------------------------------------------------------------
>> >----- Register Now & Save for Velocity, the Web Performance &
>> Operations
>> > Conference from O'Reilly Media. Velocity features a full day of
>> > expert-led, hands-on workshops and two days of sessions from industry
>> > leaders in dedicated Performance & Operations tracks. Use code
>> vel09scf
>> > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>>
>> ---------------------------------------------------------------------------
>>-----
>>
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@...
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ---------------------------------------------------------------------------
>>--- Register Now & Save for Velocity, the Web Performance & Operations
>> Conference from O'Reilly Media. Velocity features a full day of
>> expert-led, hands-on workshops and two days of sessions from industry
>> leaders in dedicated Performance & Operations tracks. Use code vel09scf
>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@...
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
> i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Felipe Sateler]

I'm taking a shot at replacing the current spinlock implementation with
mutexes. However, it seems that it will require an API bump:

PUBLIC int *csoundGetChannelLock

I don't get why do locks have to be exported, though.

El lunes 11 de mayo, jpff@... escribió:

> Indeed.  Talking it over with local experts I had concluded that we should
> use mutexes until and unless we have a need for spinlocks.  I was going to
> attemot that change when time allowed.  Feel free......
> =John ff
>
> > Perhaps we could use mutexes as a start and then optionally change them
> > to spinlocks when supported. Since using either is very similar in
> > pthreads implementation, we can switch them to test if spinlocks are
> > effectively faster.
> >
> > El viernes 1 de mayo, michael.gogins@... escribió:
> >> Performance is indeed the motivation for these spinlocks. I am looking
> >> to
> >> the near future where 4 or more cores are running Csound instruments on
> >> up
> >> to dozens of threads. In that case, spinlocks seem to promise a
> >> significant
> >> performance advantage over mutexes, especially because we would not
> >> expect
> >> the locks to do much actual spinning. Each lock contention would be in
> >> cache and involve a short loop and some CAS, rather than hopping out to
> >> the
> >> OS.
> >>
> >> Regards,
> >> Mike
> >>
> >> ----- Original Message -----
> >> From: "Felipe Sateler" <fsateler@...>
> >> To: "Developer discussions" <csound-devel@...>
> >> Sent: Friday, May 01, 2009 12:05 AM
> >> Subject: Re: [Cs-dev] Spinlocks
> >>
> >> > ----------------------------------------------------------------------
> >> >--- ----- Register Now & Save for Velocity, the Web Performance &
> >>
> >> Operations
> >>
> >> > Conference from O'Reilly Media. Velocity features a full day of
> >> > expert-led, hands-on workshops and two days of sessions from industry
> >> > leaders in dedicated Performance & Operations tracks. Use code
> >>
> >> vel09scf
> >>
> >> > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> >>
> >> ------------------------------------------------------------------------
> >>--- -----
> >>
> >> > _______________________________________________
> >> > Csound-devel mailing list
> >> > Csound-devel@...
> >> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >>
> >> ------------------------------------------------------------------------
> >>--- --- Register Now & Save for Velocity, the Web Performance &
> >> Operations Conference from O'Reilly Media. Velocity features a full day
> >> of expert-led, hands-on workshops and two days of sessions from industry
> >> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> >> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> >> _______________________________________________
> >> Csound-devel mailing list
> >> Csound-devel@...
> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> > Saludos,
> > Felipe Sateler
> >
> > -------------------------------------------------------------------------
> >----- The NEW KODAK i700 Series Scanners deliver under ANY circumstances!
> > Your production scanning environment may not be a perfect world - but
> > thanks to Kodak, there's a perfect scanner to get the job done! With the
> > NEW KODAK i700
> > Series Scanner you'll get full speed at 300 dpi even with all image
> > processing features enabled. http://p.sf.net/sfu/kodak-com
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@...
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ---------------------------------------------------------------------------
>--- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
> i700 Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Michael Gogins-2]

I chose spinlocks over mutexes because with more than a couple of
cores and real-time ksmps, spinlocks seem very likely to be more
efficient. Think about 16 cores and kr = 8820.

Do you really, really want to make a system call 141,120 times per second?

Locks are exported because in future opcodes may need to call them. We
do not yet know if opcode writers will need to pay attention to
locking and unlock things in the Csound core.

It does no harm to export them, and may cause harm not to export them.

Regards,
Mike

On 5/11/09, Felipe Sateler <fsateler@...> wrote:

> I'm taking a shot at replacing the current spinlock implementation with
> mutexes. However, it seems that it will require an API bump:
>
> PUBLIC int *csoundGetChannelLock
>
> I don't get why do locks have to be exported, though.
>
> El lunes 11 de mayo, jpff@... escribió:
>> Indeed.  Talking it over with local experts I had concluded that we should
>> use mutexes until and unless we have a need for spinlocks.  I was going to
>> attemot that change when time allowed.  Feel free......
>> =John ff
>>
>> > Perhaps we could use mutexes as a start and then optionally change them
>> > to spinlocks when supported. Since using either is very similar in
>> > pthreads implementation, we can switch them to test if spinlocks are
>> > effectively faster.
>> >
>> > El viernes 1 de mayo, michael.gogins@... escribió:
>> >> Performance is indeed the motivation for these spinlocks. I am looking
>> >> to
>> >> the near future where 4 or more cores are running Csound instruments on
>> >> up
>> >> to dozens of threads. In that case, spinlocks seem to promise a
>> >> significant
>> >> performance advantage over mutexes, especially because we would not
>> >> expect
>> >> the locks to do much actual spinning. Each lock contention would be in
>> >> cache and involve a short loop and some CAS, rather than hopping out to
>> >> the
>> >> OS.
>> >>
>> >> Regards,
>> >> Mike
>> >>
>> >> ----- Original Message -----
>> >> From: "Felipe Sateler" <fsateler@...>
>> >> To: "Developer discussions" <csound-devel@...>
>> >> Sent: Friday, May 01, 2009 12:05 AM
>> >> Subject: Re: [Cs-dev] Spinlocks
>> >>
>> >> > ----------------------------------------------------------------------
>> >> >--- ----- Register Now & Save for Velocity, the Web Performance &
>> >>
>> >> Operations
>> >>
>> >> > Conference from O'Reilly Media. Velocity features a full day of
>> >> > expert-led, hands-on workshops and two days of sessions from industry
>> >> > leaders in dedicated Performance & Operations tracks. Use code
>> >>
>> >> vel09scf
>> >>
>> >> > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>> >>
>> >> ------------------------------------------------------------------------
>> >>--- -----
>> >>
>> >> > _______________________________________________
>> >> > Csound-devel mailing list
>> >> > Csound-devel@...
>> >> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>
>> >> ------------------------------------------------------------------------
>> >>--- --- Register Now & Save for Velocity, the Web Performance &
>> >> Operations Conference from O'Reilly Media. Velocity features a full day
>> >> of expert-led, hands-on workshops and two days of sessions from
>> >> industry
>> >> leaders in dedicated Performance & Operations tracks. Use code vel09scf
>> >> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>> >> _______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@...
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>> > Saludos,
>> > Felipe Sateler
>> >
>> > -------------------------------------------------------------------------
>> >----- The NEW KODAK i700 Series Scanners deliver under ANY circumstances!
>> > Your production scanning environment may not be a perfect world - but
>> > thanks to Kodak, there's a perfect scanner to get the job done! With the
>> > NEW KODAK i700
>> > Series Scanner you'll get full speed at 300 dpi even with all image
>> > processing features enabled. http://p.sf.net/sfu/kodak-com
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@...
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ---------------------------------------------------------------------------
>>--- The NEW KODAK i700 Series Scanners deliver under ANY circumstances!
>> Your
>> production scanning environment may not be a perfect world - but thanks to
>> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
>> i700 Series Scanner you'll get full speed at 300 dpi even with all image
>> processing features enabled. http://p.sf.net/sfu/kodak-com
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@...
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
> i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

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

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[jpff-2]

One could leave the API unchanged if the int was used as an index into a
tatable of pthread_mutex_t*
  Painful but saves all the gassle of API change?

I still think mutexs are better that spinlocks; with the parallel Csound
we have seen scheduling problems with spinlocks.

==John ff

> I'm taking a shot at replacing the current spinlock implementation with
> mutexes. However, it seems that it will require an API bump:
>
> PUBLIC int *csoundGetChannelLock
>
> I don't get why do locks have to be exported, though.
>
> El lunes 11 de mayo, jpff@... escribió:
>> Indeed.  Talking it over with local experts I had concluded that we
>> should
>> use mutexes until and unless we have a need for spinlocks.  I was going
>> to
>> attemot that change when time allowed.  Feel free......
>> =John ff
>>
>> > Perhaps we could use mutexes as a start and then optionally change
>> them
>> > to spinlocks when supported. Since using either is very similar in
>> > pthreads implementation, we can switch them to test if spinlocks are
>> > effectively faster.
>> >
>> > El viernes 1 de mayo, michael.gogins@... escribió:
>> >> Performance is indeed the motivation for these spinlocks. I am
>> looking
>> >> to
>> >> the near future where 4 or more cores are running Csound instruments
>> on
>> >> up
>> >> to dozens of threads. In that case, spinlocks seem to promise a
>> >> significant
>> >> performance advantage over mutexes, especially because we would not
>> >> expect
>> >> the locks to do much actual spinning. Each lock contention would be
>> in
>> >> cache and involve a short loop and some CAS, rather than hopping out
>> to
>> >> the
>> >> OS.
>> >>
>> >> Regards,
>> >> Mike
>> >>
>> >> ----- Original Message -----
>> >> From: "Felipe Sateler" <fsateler@...>
>> >> To: "Developer discussions" <csound-devel@...>
>> >> Sent: Friday, May 01, 2009 12:05 AM
>> >> Subject: Re: [Cs-dev] Spinlocks
>> >>
>> >> > ----------------------------------------------------------------------
>> >> >--- ----- Register Now & Save for Velocity, the Web Performance &
>> >>
>> >> Operations
>> >>
>> >> > Conference from O'Reilly Media. Velocity features a full day of
>> >> > expert-led, hands-on workshops and two days of sessions from
>> industry
>> >> > leaders in dedicated Performance & Operations tracks. Use code
>> >>
>> >> vel09scf
>> >>
>> >> > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>> >>
>> >> ------------------------------------------------------------------------
>> >>--- -----
>> >>
>> >> > _______________________________________________
>> >> > Csound-devel mailing list
>> >> > Csound-devel@...
>> >> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>
>> >> ------------------------------------------------------------------------
>> >>--- --- Register Now & Save for Velocity, the Web Performance &
>> >> Operations Conference from O'Reilly Media. Velocity features a full
>> day
>> >> of expert-led, hands-on workshops and two days of sessions from
>> industry
>> >> leaders in dedicated Performance & Operations tracks. Use code
>> vel09scf
>> >> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>> >> _______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@...
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>> > Saludos,
>> > Felipe Sateler
>> >
>> > -------------------------------------------------------------------------
>> >----- The NEW KODAK i700 Series Scanners deliver under ANY
>> circumstances!
>> > Your production scanning environment may not be a perfect world - but
>> > thanks to Kodak, there's a perfect scanner to get the job done! With
>> the
>> > NEW KODAK i700
>> > Series Scanner you'll get full speed at 300 dpi even with all image
>> > processing features enabled. http://p.sf.net/sfu/kodak-com
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@...
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ---------------------------------------------------------------------------
>>--- The NEW KODAK i700 Series Scanners deliver under ANY circumstances!
>> Your
>> production scanning environment may not be a perfect world - but thanks
>> to
>> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
>> i700 Series Scanner you'll get full speed at 300 dpi even with all image
>> processing features enabled. http://p.sf.net/sfu/kodak-com
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@...
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
> i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Felipe Sateler]

El lunes 11 de mayo, Michael Gogins escribió:
> I chose spinlocks over mutexes because with more than a couple of
> cores and real-time ksmps, spinlocks seem very likely to be more
> efficient. Think about 16 cores and kr = 8820.
>
> Do you really, really want to make a system call 141,120 times per second?

No, I don't. However, once the the threading logic is correct, one can
optimize and choose alternate implementations. It appears that there are pre-
made spinlock implementations for all platforms, although none cross-platform.
Having a default and correct (albeit slow) implementation makes it easier to
start using these platform-dependent spinlocks on a case by case basis, given
sufficient abstraction.

>
> Locks are exported because in future opcodes may need to call them. We
> do not yet know if opcode writers will need to pay attention to
> locking and unlock things in the Csound core.
>
> It does no harm to export them, and may cause harm not to export them.

I would think otherwise. Until an opcode appears that needs to access locks,
locks should be hidden. A lock is a very low level thing. Csound should
provide the higher level access functions instead.


Saludos,
Felipe Sateler

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Felipe Sateler]

Since nobody is using these functions yet we can consider them an error, and
stop exporting them. Technically we changed the API, but no harm is done.

El lunes 11 de mayo, jpff@... escribió:

> One could leave the API unchanged if the int was used as an index into a
> tatable of pthread_mutex_t*
>   Painful but saves all the gassle of API change?
>
> I still think mutexs are better that spinlocks; with the parallel Csound
> we have seen scheduling problems with spinlocks.
>
> ==John ff
>
> > I'm taking a shot at replacing the current spinlock implementation with
> > mutexes. However, it seems that it will require an API bump:
> >
> > PUBLIC int *csoundGetChannelLock
> >
> > I don't get why do locks have to be exported, though.
> >
> > El lunes 11 de mayo, jpff@... escribió:
> >> Indeed.  Talking it over with local experts I had concluded that we
> >> should
> >> use mutexes until and unless we have a need for spinlocks.  I was going
> >> to
> >> attemot that change when time allowed.  Feel free......
> >> =John ff
> >>
> >> > Perhaps we could use mutexes as a start and then optionally change
> >>
> >> them
> >>
> >> > to spinlocks when supported. Since using either is very similar in
> >> > pthreads implementation, we can switch them to test if spinlocks are
> >> > effectively faster.
> >> >
> >> > El viernes 1 de mayo, michael.gogins@... escribió:
> >> >> Performance is indeed the motivation for these spinlocks. I am
> >>
> >> looking
> >>
> >> >> to
> >> >> the near future where 4 or more cores are running Csound instruments
> >>
> >> on
> >>
> >> >> up
> >> >> to dozens of threads. In that case, spinlocks seem to promise a
> >> >> significant
> >> >> performance advantage over mutexes, especially because we would not
> >> >> expect
> >> >> the locks to do much actual spinning. Each lock contention would be
> >>
> >> in
> >>
> >> >> cache and involve a short loop and some CAS, rather than hopping out
> >>
> >> to
> >>
> >> >> the
> >> >> OS.
> >> >>
> >> >> Regards,
> >> >> Mike
> >> >>
> >> >> ----- Original Message -----
> >> >> From: "Felipe Sateler" <fsateler@...>
> >> >> To: "Developer discussions" <csound-devel@...>
> >> >> Sent: Friday, May 01, 2009 12:05 AM
> >> >> Subject: Re: [Cs-dev] Spinlocks
> >> >>
> >> >> > -------------------------------------------------------------------
> >> >> >--- --- ----- Register Now & Save for Velocity, the Web Performance
> >> >> > &
> >> >>
> >> >> Operations
> >> >>
> >> >> > Conference from O'Reilly Media. Velocity features a full day of
> >> >> > expert-led, hands-on workshops and two days of sessions from
> >>
> >> industry
> >>
> >> >> > leaders in dedicated Performance & Operations tracks. Use code
> >> >>
> >> >> vel09scf
> >> >>
> >> >> > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >>--- --- -----
> >> >>
> >> >> > _______________________________________________
> >> >> > Csound-devel mailing list
> >> >> > Csound-devel@...
> >> >> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >>--- --- --- Register Now & Save for Velocity, the Web Performance &
> >> >> Operations Conference from O'Reilly Media. Velocity features a full
> >>
> >> day
> >>
> >> >> of expert-led, hands-on workshops and two days of sessions from
> >>
> >> industry
> >>
> >> >> leaders in dedicated Performance & Operations tracks. Use code
> >>
> >> vel09scf
> >>
> >> >> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> >> >> _______________________________________________
> >> >> Csound-devel mailing list
> >> >> Csound-devel@...
> >> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
> >> >
> >> > Saludos,
> >> > Felipe Sateler
> >> >
> >> > ----------------------------------------------------------------------
> >> >--- ----- The NEW KODAK i700 Series Scanners deliver under ANY
> >>
> >> circumstances!
> >>
> >> > Your production scanning environment may not be a perfect world - but
> >> > thanks to Kodak, there's a perfect scanner to get the job done! With
> >>
> >> the
> >>
> >> > NEW KODAK i700
> >> > Series Scanner you'll get full speed at 300 dpi even with all image
> >> > processing features enabled. http://p.sf.net/sfu/kodak-com
> >> > _______________________________________________
> >> > Csound-devel mailing list
> >> > Csound-devel@...
> >> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >>
> >> ------------------------------------------------------------------------
> >>--- --- The NEW KODAK i700 Series Scanners deliver under ANY
> >> circumstances! Your
> >> production scanning environment may not be a perfect world - but thanks
> >> to
> >> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
> >> i700 Series Scanner you'll get full speed at 300 dpi even with all image
> >> processing features enabled. http://p.sf.net/sfu/kodak-com
> >> _______________________________________________
> >> Csound-devel mailing list
> >> Csound-devel@...
> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> > Saludos,
> > Felipe Sateler
> >
> > -------------------------------------------------------------------------
> >----- The NEW KODAK i700 Series Scanners deliver under ANY circumstances!
> > Your production scanning environment may not be a perfect world - but
> > thanks to Kodak, there's a perfect scanner to get the job done! With the
> > NEW KODAK i700
> > Series Scanner you'll get full speed at 300 dpi even with all image
> > processing features enabled. http://p.sf.net/sfu/kodak-com
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@...
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ---------------------------------------------------------------------------
>--- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
> i700 Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Saludos,
Felipe Sateler


------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Michael Gogins-2]

I am using them. Please do not remove them unless you replace them
with something else that does the same job, only better. If you do
remove them I will put them back.

Regards,
Mike

On 5/24/09, Felipe Sateler <fsateler@...> wrote:

> Since nobody is using these functions yet we can consider them an error, and
> stop exporting them. Technically we changed the API, but no harm is done.
>
> El lunes 11 de mayo, jpff@... escribió:
>> One could leave the API unchanged if the int was used as an index into a
>> tatable of pthread_mutex_t*
>>   Painful but saves all the gassle of API change?
>>
>> I still think mutexs are better that spinlocks; with the parallel Csound
>> we have seen scheduling problems with spinlocks.
>>
>> ==John ff
>>
>> > I'm taking a shot at replacing the current spinlock implementation with
>> > mutexes. However, it seems that it will require an API bump:
>> >
>> > PUBLIC int *csoundGetChannelLock
>> >
>> > I don't get why do locks have to be exported, though.
>> >
>> > El lunes 11 de mayo, jpff@... escribió:
>> >> Indeed.  Talking it over with local experts I had concluded that we
>> >> should
>> >> use mutexes until and unless we have a need for spinlocks.  I was going
>> >> to
>> >> attemot that change when time allowed.  Feel free......
>> >> =John ff
>> >>
>> >> > Perhaps we could use mutexes as a start and then optionally change
>> >>
>> >> them
>> >>
>> >> > to spinlocks when supported. Since using either is very similar in
>> >> > pthreads implementation, we can switch them to test if spinlocks are
>> >> > effectively faster.
>> >> >
>> >> > El viernes 1 de mayo, michael.gogins@... escribió:
>> >> >> Performance is indeed the motivation for these spinlocks. I am
>> >>
>> >> looking
>> >>
>> >> >> to
>> >> >> the near future where 4 or more cores are running Csound instruments
>> >>
>> >> on
>> >>
>> >> >> up
>> >> >> to dozens of threads. In that case, spinlocks seem to promise a
>> >> >> significant
>> >> >> performance advantage over mutexes, especially because we would not
>> >> >> expect
>> >> >> the locks to do much actual spinning. Each lock contention would be
>> >>
>> >> in
>> >>
>> >> >> cache and involve a short loop and some CAS, rather than hopping out
>> >>
>> >> to
>> >>
>> >> >> the
>> >> >> OS.
>> >> >>
>> >> >> Regards,
>> >> >> Mike
>> >> >>
>> >> >> ----- Original Message -----
>> >> >> From: "Felipe Sateler" <fsateler@...>
>> >> >> To: "Developer discussions" <csound-devel@...>
>> >> >> Sent: Friday, May 01, 2009 12:05 AM
>> >> >> Subject: Re: [Cs-dev] Spinlocks
>> >> >>
>> >> >> > -------------------------------------------------------------------
>> >> >> >--- --- ----- Register Now & Save for Velocity, the Web Performance
>> >> >> > &
>> >> >>
>> >> >> Operations
>> >> >>
>> >> >> > Conference from O'Reilly Media. Velocity features a full day of
>> >> >> > expert-led, hands-on workshops and two days of sessions from
>> >>
>> >> industry
>> >>
>> >> >> > leaders in dedicated Performance & Operations tracks. Use code
>> >> >>
>> >> >> vel09scf
>> >> >>
>> >> >> > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >>--- --- -----
>> >> >>
>> >> >> > _______________________________________________
>> >> >> > Csound-devel mailing list
>> >> >> > Csound-devel@...
>> >> >> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >>--- --- --- Register Now & Save for Velocity, the Web Performance &
>> >> >> Operations Conference from O'Reilly Media. Velocity features a full
>> >>
>> >> day
>> >>
>> >> >> of expert-led, hands-on workshops and two days of sessions from
>> >>
>> >> industry
>> >>
>> >> >> leaders in dedicated Performance & Operations tracks. Use code
>> >>
>> >> vel09scf
>> >>
>> >> >> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>> >> >> _______________________________________________
>> >> >> Csound-devel mailing list
>> >> >> Csound-devel@...
>> >> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >> >
>> >> > Saludos,
>> >> > Felipe Sateler
>> >> >
>> >> > ----------------------------------------------------------------------
>> >> >--- ----- The NEW KODAK i700 Series Scanners deliver under ANY
>> >>
>> >> circumstances!
>> >>
>> >> > Your production scanning environment may not be a perfect world - but
>> >> > thanks to Kodak, there's a perfect scanner to get the job done! With
>> >>
>> >> the
>> >>
>> >> > NEW KODAK i700
>> >> > Series Scanner you'll get full speed at 300 dpi even with all image
>> >> > processing features enabled. http://p.sf.net/sfu/kodak-com
>> >> > _______________________________________________
>> >> > Csound-devel mailing list
>> >> > Csound-devel@...
>> >> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>
>> >> ------------------------------------------------------------------------
>> >>--- --- The NEW KODAK i700 Series Scanners deliver under ANY
>> >> circumstances! Your
>> >> production scanning environment may not be a perfect world - but thanks
>> >> to
>> >> Kodak, there's a perfect scanner to get the job done! With the NEW
>> >> KODAK
>> >> i700 Series Scanner you'll get full speed at 300 dpi even with all
>> >> image
>> >> processing features enabled. http://p.sf.net/sfu/kodak-com
>> >> _______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@...
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>> > Saludos,
>> > Felipe Sateler
>> >
>> > -------------------------------------------------------------------------
>> >----- The NEW KODAK i700 Series Scanners deliver under ANY circumstances!
>> > Your production scanning environment may not be a perfect world - but
>> > thanks to Kodak, there's a perfect scanner to get the job done! With the
>> > NEW KODAK i700
>> > Series Scanner you'll get full speed at 300 dpi even with all image
>> > processing features enabled. http://p.sf.net/sfu/kodak-com
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@...
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ---------------------------------------------------------------------------
>>--- The NEW KODAK i700 Series Scanners deliver under ANY circumstances!
>> Your
>> production scanning environment may not be a perfect world - but thanks to
>> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
>> i700 Series Scanner you'll get full speed at 300 dpi even with all image
>> processing features enabled. http://p.sf.net/sfu/kodak-com
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@...
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> Saludos,
> Felipe Sateler
>

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

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Felipe Sateler]

Don't worry, I won't remove them if someone is using them. And also
wasn't planning on removing them if there was no consensus.

Saludos,
Felipe Sateler



On Mon, May 25, 2009 at 01:25, Michael Gogins <michael.gogins@...> wrote:

> I am using them. Please do not remove them unless you replace them
> with something else that does the same job, only better. If you do
> remove them I will put them back.
>
> Regards,
> Mike
>
> On 5/24/09, Felipe Sateler <fsateler@...> wrote:
>> Since nobody is using these functions yet we can consider them an error, and
>> stop exporting them. Technically we changed the API, but no harm is done.
>>
>> El lunes 11 de mayo, jpff@... escribió:
>>> One could leave the API unchanged if the int was used as an index into a
>>> tatable of pthread_mutex_t*
>>>   Painful but saves all the gassle of API change?
>>>
>>> I still think mutexs are better that spinlocks; with the parallel Csound
>>> we have seen scheduling problems with spinlocks.
>>>
>>> ==John ff
>>>
>>> > I'm taking a shot at replacing the current spinlock implementation with
>>> > mutexes. However, it seems that it will require an API bump:
>>> >
>>> > PUBLIC int *csoundGetChannelLock
>>> >
>>> > I don't get why do locks have to be exported, though.
>>> >
>>> > El lunes 11 de mayo, jpff@... escribió:
>>> >> Indeed.  Talking it over with local experts I had concluded that we
>>> >> should
>>> >> use mutexes until and unless we have a need for spinlocks.  I was going
>>> >> to
>>> >> attemot that change when time allowed.  Feel free......
>>> >> =John ff
>>> >>
>>> >> > Perhaps we could use mutexes as a start and then optionally change
>>> >>
>>> >> them
>>> >>
>>> >> > to spinlocks when supported. Since using either is very similar in
>>> >> > pthreads implementation, we can switch them to test if spinlocks are
>>> >> > effectively faster.
>>> >> >
>>> >> > El viernes 1 de mayo, michael.gogins@... escribió:
>>> >> >> Performance is indeed the motivation for these spinlocks. I am
>>> >>
>>> >> looking
>>> >>
>>> >> >> to
>>> >> >> the near future where 4 or more cores are running Csound instruments
>>> >>
>>> >> on
>>> >>
>>> >> >> up
>>> >> >> to dozens of threads. In that case, spinlocks seem to promise a
>>> >> >> significant
>>> >> >> performance advantage over mutexes, especially because we would not
>>> >> >> expect
>>> >> >> the locks to do much actual spinning. Each lock contention would be
>>> >>
>>> >> in
>>> >>
>>> >> >> cache and involve a short loop and some CAS, rather than hopping out
>>> >>
>>> >> to
>>> >>
>>> >> >> the
>>> >> >> OS.
>>> >> >>
>>> >> >> Regards,
>>> >> >> Mike
>>> >> >>
>>> >> >> ----- Original Message -----
>>> >> >> From: "Felipe Sateler" <fsateler@...>
>>> >> >> To: "Developer discussions" <csound-devel@...>
>>> >> >> Sent: Friday, May 01, 2009 12:05 AM
>>> >> >> Subject: Re: [Cs-dev] Spinlocks
>>> >> >>
>>> >> >> > -------------------------------------------------------------------
>>> >> >> >--- --- ----- Register Now & Save for Velocity, the Web Performance
>>> >> >> > &
>>> >> >>
>>> >> >> Operations
>>> >> >>
>>> >> >> > Conference from O'Reilly Media. Velocity features a full day of
>>> >> >> > expert-led, hands-on workshops and two days of sessions from
>>> >>
>>> >> industry
>>> >>
>>> >> >> > leaders in dedicated Performance & Operations tracks. Use code
>>> >> >>
>>> >> >> vel09scf
>>> >> >>
>>> >> >> > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>>> >> >>
>>> >> >> ---------------------------------------------------------------------
>>> >> >>--- --- -----
>>> >> >>
>>> >> >> > _______________________________________________
>>> >> >> > Csound-devel mailing list
>>> >> >> > Csound-devel@...
>>> >> >> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >> >>
>>> >> >> ---------------------------------------------------------------------
>>> >> >>--- --- --- Register Now & Save for Velocity, the Web Performance &
>>> >> >> Operations Conference from O'Reilly Media. Velocity features a full
>>> >>
>>> >> day
>>> >>
>>> >> >> of expert-led, hands-on workshops and two days of sessions from
>>> >>
>>> >> industry
>>> >>
>>> >> >> leaders in dedicated Performance & Operations tracks. Use code
>>> >>
>>> >> vel09scf
>>> >>
>>> >> >> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>>> >> >> _______________________________________________
>>> >> >> Csound-devel mailing list
>>> >> >> Csound-devel@...
>>> >> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >> >
>>> >> > Saludos,
>>> >> > Felipe Sateler
>>> >> >
>>> >> > ----------------------------------------------------------------------
>>> >> >--- ----- The NEW KODAK i700 Series Scanners deliver under ANY
>>> >>
>>> >> circumstances!
>>> >>
>>> >> > Your production scanning environment may not be a perfect world - but
>>> >> > thanks to Kodak, there's a perfect scanner to get the job done! With
>>> >>
>>> >> the
>>> >>
>>> >> > NEW KODAK i700
>>> >> > Series Scanner you'll get full speed at 300 dpi even with all image
>>> >> > processing features enabled. http://p.sf.net/sfu/kodak-com
>>> >> > _______________________________________________
>>> >> > Csound-devel mailing list
>>> >> > Csound-devel@...
>>> >> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >>
>>> >> ------------------------------------------------------------------------
>>> >>--- --- The NEW KODAK i700 Series Scanners deliver under ANY
>>> >> circumstances! Your
>>> >> production scanning environment may not be a perfect world - but thanks
>>> >> to
>>> >> Kodak, there's a perfect scanner to get the job done! With the NEW
>>> >> KODAK
>>> >> i700 Series Scanner you'll get full speed at 300 dpi even with all
>>> >> image
>>> >> processing features enabled. http://p.sf.net/sfu/kodak-com
>>> >> _______________________________________________
>>> >> Csound-devel mailing list
>>> >> Csound-devel@...
>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >
>>> > Saludos,
>>> > Felipe Sateler
>>> >
>>> > -------------------------------------------------------------------------
>>> >----- The NEW KODAK i700 Series Scanners deliver under ANY circumstances!
>>> > Your production scanning environment may not be a perfect world - but
>>> > thanks to Kodak, there's a perfect scanner to get the job done! With the
>>> > NEW KODAK i700
>>> > Series Scanner you'll get full speed at 300 dpi even with all image
>>> > processing features enabled. http://p.sf.net/sfu/kodak-com
>>> > _______________________________________________
>>> > Csound-devel mailing list
>>> > Csound-devel@...
>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ---------------------------------------------------------------------------
>>>--- The NEW KODAK i700 Series Scanners deliver under ANY circumstances!
>>> Your
>>> production scanning environment may not be a perfect world - but thanks to
>>> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
>>> i700 Series Scanner you'll get full speed at 300 dpi even with all image
>>> processing features enabled. http://p.sf.net/sfu/kodak-com
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> Saludos,
>> Felipe Sateler
>>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel