... just reached kind of a first milestone: the demo-test is working!
TEST::Launch ■□■□■□■□■□■□■□■□◆•Gui-Data-Exchange-Test•◆□■□■□■□■□■□■□■□■ Hello Heffalump..2f790299 Bye Bye Heffalump..2f790299 EXIT Goodbye - Play again soon?
This implies that the basic protocol implementation is in place. We can now beam arbitrary Heffalumps into the GUI... Next I have to think about thread synchronisation. The simplest possible implementation would be to use a mutex for GuiDataExchange Alternatively it seems possible to use an atomic on the index variable pointing to the "oldest" slot. However, doing it this way would be quite tricky, we'd need to do some test to allocate the slot first, and then re-check if some concurrent modification happened. Then, after copying the data we'd have to issue a second barrier. Same on reading.... hard to get right. Looks somewhat like premature optimisation... Thus I'm leaning towards KISS, i.e. write a mutex based implementation first and then see if we can find *any* performance impact. Moreover this will allow us to push ahead and start integrating it in the actual code base. And by doing so, we'll get a clearer picture as to where and when this locking will matter (will it even have an impact on the synth thread?) -- Hermann _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
