In the new FX book, there is a section on multithreading, especially involving corrupted data and race conditions. With RackAFX7, which is still 32-bit, this is an issue and I updated the API back in 2015 to address this. In the book, I use 64-bit values in the examples that discuss reading and writing partial values on thread slice boundaries. I got a really great email from a book reader today who pointed out that for 64-bit data, there is built-in atomic guarantees for data. This is most of the email he sent, along with a link for more information. I hope it helps clear up any misunderstandings. I still have threading issues in 32-bit plugins and processing. 

Quote from email:

"I think that your description of the issues surrounding multithreaded reads and writes is somewhat misleading. On a 64-bit operating system, writing ints, longs, floats and doubles is atomic in the sense that no matter how hard you try, if you concurrently write X and Y then you are guaranteed to read either X or Y, but not some corrupted combination of the two. This is because these types are all aligned to the 64-bit memory boundary and the cache line reads in 64 byte chunks, not 8 byte chunks as you suggest. The arbitrary nature of the read occurs from the fact that each thread may hold its own copy of the value, so a synchronisation mechanism is required to ensure that all threads synchronise their copy prior to accessing the variable. I think in the situation you describe of a single primitive value the worst that will happen is that the plugin slightly lags behind the DAW. For a genuinely corrupt state to occur you need either a non-primitive value, such as a string, or multiple primitive values. Specifically the data need to span the 64-bit memory boundary.

Of course on a 32-bit OS corruption of doubles and longs is possible as the cache line is only 32-bytes.

This blog post is relevant: https://codywu2010.wordpress.com/2014/11/03/is-int-write-operation-atomic-on-x86_64/