Comments by Guitar Zero (Top 2 by date)

Guitar Zero 24-Sep-14 10:07am View

Yeah, that's an awful long snippet. Sorry, this is my first post of this type. I'll see if I can trim it down to something representative that still would exhibit the same behavior. I can also pull out the two functions that were in it originally. I wasn't certain that the function calls weren't causing the problem.

As for examples, I can provide that now. This process runs inside another loop, and the iterations get bigger as they proceed, like moving by row or column in a triangular matrix. For the 6th iteration of a particular sample, the serial version makes an output file that is 12896 KB. The parallel version's output can range between 12881 and 12892, meaning that it's lost something along the way, and because each iteration of the big loop is dependent on the last one, it gets worse from there.

Guitar Zero 23-Sep-14 16:39pm View

Yes, a race condition is created when the results depend on who gets there first, and this sounds like a race. In my case, the only output is for each iteration of the loop to write to its unique position in the output array, which is only written to the file outside the loop, after it has finished. The only thing the iterations of the loop share is the input data, and I've even declared thread-local copies of that and put a SyncLock on when I set them to the (global?) values outside the loop.