Hi All,

I've just checked into CVS an initial attempt at getting csound
multithreaded.  John and I had talked a little at the LAC about
starting to move towards taking advantage of multicore systems.  The
implementation uses some code for thread barriers that John sent me to
use as a reference and currently is implemented on Linux and has stubs
there for Mac and Windows (in threads.c).  While at LAC and thinking
about how to multithread, I got to thinking about the processing order
and semantics of that.  To preserve the same exact order of processing
as the single-threaded version, I figured for an initial
implementation to do that is to basically have a thread pool and
process each set of instrument instances one at a time, i.e.
processing all of instr 1, then instr 2, etc.  kperf was changed when
--num-threads=2 or more to use barriers to call the worker threads and
wait on a barrier for them to finish. For code in instruments which
may cause race conditions, a set of mutex opcodes were written:
mutex_lock, mutex_unlock, mutex_locki, and mutex_unlocki.  I'm not
sure the i-rate versions are necessary though as i-time still
processes all in a single thread, so those might be unnecessary.

The strategy is a bit naive and inefficient, though I don't know
really what the performance is like as I only have a single core
machine.  I'd be very interested to know how the performance is like
on a multi-core machine.

Also, right now I find that using multiple threads can yield
segfaults.  I haven't had much time to look at this as I've been away
doing some work and only doing this in the little spare free time i
have at the moment, and probably won't have much free time for another
couple weeks.

I don't expect this code and strategy to be optimal in any way or that
it will yield any performance benefit in the end, but I thought it
would be worth it to try out with a pretty conservative strategy with
explicit user input for mutex locking, just to have some place to
start from.  It'd be great to get some other eyes on this code and
thoughts on how to improve it.

Thanks!
steven

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net