CPU writer / GPU reader boundary: choosing a synchronization strategy for persistent mapped buffers

Setup

I am streaming per-frame data from CPU producer code into a buffer created with glBufferStorage using GL_MAP_PERSISTENT_BIT | GL_MAP_WRITE_BIT (OpenGL 4.4 core, with ARB_buffer_storage as the extension fallback). The CPU writes into the mapped pointer while the GPU consumes earlier regions in draw calls, so both sides share one buffer.

The open decision

The unresolved part is how to signal "data ready" and "region consumed" without stalling either side. I see two documented strategies and cannot determine which trade-offs should decide between them:

• One glFenceSync per frame, with glClientWaitSync before rewriting that frame's region.
• Triple-buffered regions that simply assume N frames of latency are always safe, with no client-side wait.

I am also unsure whether to set GL_MAP_COHERENT_BIT and skip glFlushMappedBufferRange, given that coherent writes are reportedly driver-dependent in cost. Overwriting a region the GPU is still reading produces silent corruption rather than an error, so I cannot validate the choice by observing failures reliably.

Questions

1. What criteria determine whether fence-plus-wait or fixed N-frame region rotation is the safer default for a steady per-frame stream?
2. Is glWaitSync (GPU-side) ever sufficient on its own here, given that it does not block the CPU and needs a glFlush to be reliable?
3. Should coherent mapping be avoided when explicit flushes are cheap to batch, or is the driver overhead usually negligible?