Hi Michael, What I had implemented and is currently committed is really just a naive start and is only working on Linux and Mac. What happens if you enabled --num-threads=x where x > 1, that alternate performance method you found is run. It's ugly in that it find the boundaries for note instances per instrument and partitions the work for that instrument on every k-pass, which is heavy work to do IMO. It uses num-threads in a pool and uses two barriers (code came from John for the barrier), one to signal all the worker threads to start, the other to wait for all of the threads to finish their work. This works, but when I did this code last year it revealed that while Csound might be re-entrant, it still has global level variables in use. The one I found most problematic at the time was currevent on the CSOUND struct. This member is referenced by opcodes that do jumps to labels (goto's, if's, etc.). They use it to get the head of the single-y linked list of opcodes and then traverse to search for labels. This variable might be used for other things, I'm not sure, but this would definitely need to be removed for parallel processing. At the time I figured the best way would be to make the opcodes a double-y linked list so that an opcode could traverse previous to find the head itself and then walk forward to find labels. Beyond that, to continue where I left off, we'd have to implement barrier code on Windows. The work partitioning is awful as mentioned above, but it's not incorrect, meaning it could be left as-is and more important things could be addressed first like finding all the variables like currevent which are really global variables and to redo their usage to be thread-safe. This would mean doing things like protecting spin and spout, etc. Again, these are all issues that would need to be addressed regardless for any parallel solution. steven On Thu, Apr 24, 2008 at 12:14 PM, Michael Gogins wrote: > Steven, thanks for your response. I'm only going to touch on part of it. > > > > >What I see as the most likely way to achieve some benefit is to have > >worker threads partition the instances of an instrument. > > OK, let's take that as the starting point. > > > >I would say > >this is the best place to start and what we should aim for first as it > >is the easiest to achieve and still preserves all processing order of > >single-threaded csound. This is the approach taken in the work I > >committed and is in CVS, and even then it reveals that there is a lot > >of work required to handle concurrency in even this relatively simple > >approach. I would say if we do this first, we would get to focus on > >all of the essential changes required for concurrency (in other words, > >this work is foundation work we need to do no matter what the eventual > >strategy is used). > > Can you outline your general approach? > > How close is what you have done to working? What more needs to be done? > > Regards, > Mike > > > > ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net