While making the LinkAPI I stumbled upon a possible concurrency issue. After reviewing the code of the link-plugin to see how this is handled there I had to see that it is not being handled at all.
Since the shared memory is freely available for read and write (as far as the OS permits) it is possible that - due to the frequent (per frame) updates - data might have changed during the consecutive reading of members in the struct.
I am imagining a call chain of lm->xxx where the first call will get a result for dwcount 1 and the following lm->yyy will get the result for dwcount 2 - since there was an update in between.
While this may actually be insignificant and possibly negligible it constitutes unexpected behavior. As one would expect all data collected "at the same time" (i.e. the function fetch ) to be related to the same frame/dwcount, which is currently not guaranteed.
The way to fix this imho is to use a semaphore. It might be best to use what ever the OS provides regarding semaphores or use dwcount to match data. So simply if there is a dwcount mismatch from before the first and after the last read then the whole data-group is invalid.