Just use mutexes to control the handing over of one "frame" of data from one thread to another. Volatile is only needed if you're trying to reinvent mutexes yourself -- in most projects, use of the volatile keyword is simply banned: if you try to use it, the team will just assume that your code is buggy, because it most likely is (unless you're the kind of guy who understands all the OS, compiler and hardware specific details required to properly implement your own synchronization primitives, and has written multiple unit-tests that have been running for 6 months across different hardware configurations just to be sure ).
You might want to have storage for 3 frames's worth. Say the renderer is reading one of those buffers, and the updater is writing one. If the updater finishes it's work, it can't start a new frame because there's no free buffers (it must wait for the renderer to finish reading one). A 3rd buffer lets the updater start a new frame immediately. YMMV
Make an array of structures that describe which tread owns each buffer, and on which frame it was generated. Make a mutex that protects these structures.
When the render thread starts a frame, lock the mutex and loop through the structure to find the most recent frame that isn't owned by any thread at the moment. Mark it as owned by the renderer, unlock the mutex and render from it. When you're done, lock the mutex, mark it as non-owned and unlock the mutex.
When the update thread starts a frame, lock the mutex, find the oldest non-owned buffer, mark it as owned by the updater, unlock, write a new frame to it, lock, mark as non-owned, unlock.