Code sharing - high performance synchronisation of data in multi threaded Windows applications

[Robert Walker]

Hi everyone, especially coders writing in Windows C, during the MELM some of the other coders discussed this with me. 

In my programs then I let the user vary the parameters while the tune is playing. This is quite a coding challenge especially in Windows. The problem is that since the tune is a separate thread then it may well try to play notes while the data is mid-update e.g. if user changes the scale and the data isn't quite updated yet internally, it might use the new number of notes for the scale, but the old scale values.

To handle that you need methods of synchronising data between the user interface and the tune playing thread. But the standard methods of data synchronisation that come with Windows are far too slow for this type of situation where every millisecond counts. Anyone who tries them soon realises they need something faster.

This shows one solution, the way I do it:

http://robertinventor.com/bmwiki/High_performance_critical_sections_using_InterlockedExchange

There are several more coding issues I can write about related to this. One is high precision measurement of time - on modern computers you measure time to sub millisecond levels of precision using high resolution timers, but the code to do that isn't so widely known.

Another thing is high precision scheduling of events - if you use the normal Windows routines to schedule events you get errors of several milliseconds. Windows can easily handle millisecond precision but you need to know how to tell it to do that. You can even play notes at sub-millisecond precision if you use a busy wait for the remaining fraction of a millisecond.

Another thing is relaying sysexes - if you do midi relaying correctly you can relay dozens of midi events in a millisecond, even dozens of tuning table sysexes in a millisecond, so you should be able to receive and send a complete midi tuning sysex in much less than a millisecond, but there are a few gotchas, so if you can't do that then it might be useful to see example code.

If this is useful to anyone, I'll do those and more articles like this. If anyone has any questions about  how to code anything I do in FTS do let me know, there are dozens of tweaks and tricks and tips in the Tune Smithy code, probably hundreds of them that I've  had to deal with and research into and some took ages to find a solution to. I'm keen to share my discoveries if anyone needs them.

Thanks,

Robert

[Robert Walker]

Hi fellow coders,

For anyone interested in high performance critical sections for Windows, I've added a new "stress testing" section to the page, as a console app in Windows C.

http://robertinventor.com/bmwiki/High_performance_critical_sections_using_InterlockedExchange

So you can try it out, and see how the code fails if you just use a simple assignment. Makes it clear how use of InterlockedExchange solves the problem.

Also did more research into the background, more links and better explanation of how and why you code it like this. 

The main thing InterlockedExchange does is to combine a conditional if with an assignment into a single atomic statement. So I'd forgotten about that when I wrote the first version of the article. Anyway it's all explained clearly now.

Also added a link to Peterson's algorithm which gives a purely software (so multi-platform) implementation of critical sections - though it does require memory barriers.

Robert

--
MANAGERS ONLY: To post to MELM" group, send email to mton...@googlegroups.com
To unsubscribe from this group, send email to mtonalist+...@googlegroups.com
 
GOOGLE TRANSLATE IT: http://translate.google.com.tr