When the system is capable of sharing resources by threads or interruptions, race conditions is an extremely difficult source of bugs, therefore race conditions shall be avoided.
Race conditions produce outputs that vary depending of the order which the instructions of a function are executed (either by application or ISRs).
An example of a Race condition is when main program and ISR share the same variable “X“. When one interruption happens, ISR increment X, and application decrements X when X has a non-zero value. If X is modified by application but just before updating X value into memory, an interruption occurs, then X will be modified also by the ISR. The problem here is that the context saved from application will “overwrite” the ISR value and return to the original X as if the interruption never occurred.
To solve race conditions, the application part where X is changed shall be wrapped by an interruption disabling. Then, X assignment is a critical session. Try to minimize the number of critical sessions and their length. This is to avoid the retarding of the system response.