Volatile is used instead of atomics in several places, which is not equivalent and not necessarily safe (for more on this, see https://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/ ). In particular, the following files use volatiles where atomics should be used:

- events/SDL_events.c: SDL_EventQ, with its active/count/max_events_seen fields
- timer/SDL_timer.c: _SDL_Timer's cancelled field, SDL_TimerData's pending/freelist/active fields
- video/android/SDL_androidtouch.c: Static variable separate_mouse_and_touch
- haptic/windows/SDL_windowshaptic_c.h: haptic_hwdata's stopTicks/stopThreads fields
- Several tests additionally use volatiles when they probably shouldn't.

There are a handful of places where volatiles are used in conjunction with assembly, rather than in place of atomics, which do not need to be changed.

It doesn't seem like the use of volatiles is specifically intended, as there are at least a few cases where both atomics and volatiles are used within the same structure.

My understanding is that helgrind will treat contended loads from variables marked `volatile` as just as invalid as a normal load. I have gotten errors in helgrind from the SDL timer subsystem in the past. The errors in helgrind are what originally indicated the use of volatiles in place of atomics to me.

As long as SDL is only ever used on x86 (or other strongly-ordered architectures) or in single-threaded applications (or more specifically, an application which only ever calls SDL from one thread), the issues with using volatiles over atomics will probably never surface. However, it may be a problem when both of those constraints are not present (such as a multi-threaded ARMv7/PPC application).