I spent an entire course on race conditions and concurency in grad school, and to avoid race conditions you have to understand why they arise.
Race conditions occur when multiple concurent or parallel processes access a shared resource. Furthurmore it is mostly troublesome when 2 or more threads/processes are activly modifying a resource. So first identify the candidates for this when architecting your application. If you only have one thread you should be safe (although this is getting more fuzzy since there is the ability to run in parallel). Next is there any resources/variables that are needed in 2 threads at the same time, and if so do you modify the value in one or more threads. If so you have to deal with synchronization.
Traditionally you talk about semaphors, locks and mutexs. All methods for locking critical code (ie resources that are possible race condition sources).
BUT WE ARE IN LABVIEW. Labview has one easy method that could be easier to use, the functional global.
since vis that are not marked for reentrancy are essentially nice way for protecting data and locking your critacal sections. Only one thread can access and or modify the data stored in the vi at a time. Other threads will block and wait on the resource.
This was much harder to implement in c.
Either way the way you deal with race conditions is to
1. Identify critical sections and resources that can cause race conditions (usually shared resources with multiple writers)
2. Lock the resource until done (avoid deadlocks while doing so-but this is another discussion)
Unlike traditional bugs, concurent bugs are more random and very difficult to reproduce/test for so you will have to deal with them in the design architecture stage.
