well, it appears that the barrier code is OK for
the Mac as it's basic pthread-based. So I have tentatively
committed it as well. Will need testing, but it should
work as it does on Linux.

Now we just need to do the same for Win3-threads.

Victor

>
> 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
> https://lists.sourceforge.net/lists/listinfo/csound-devel

-------------------------------------------------------------------------
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