I have no idea what these “other synchronization techniques to ensure correct operation” could be, apart from glFlush. If you already know that the buffer is synced and safe to modify - you can just Map it - I doubt MAP_UNSYNCHRONIZED_BIT will make much difference if a sync is not needed anyway.
The way to use MapBufferRange for updating a range of the buffer - is to first invalidate a range( MAP_INVALIDATE_RANGE_BIT) and then write the new data in that range. This way if the buffer cannot be mapped immediately - the driver can allocate another buffer in graphic memory, store the changed data there and copy it to the final buffer when it is available. Still requires an extra copy. [/QUOTE]
The “other synchronization techniques” are fences as provided by APPLE_fence, ARB_sync or OpenGL 3.2. When MAP_UNSYNCHRONIZED_BIT is set, the driver will not wait until the command queue drains of any command referencing the buffer object and instead allow you to map it immediately. It then becomes the responsibility of the application to keep track of which ranges in the buffer object may be currently used by the GPU. Of course, to use this option effectively, you also need to be able to flush sub-ranges of the buffer object.
MAP_INVALIDATE_RANGE_BIT is a hint to the driver that it may create a new allocation or at least avoid copying any data from the on-GPU buffer object and just hand the application a pointer. And so yes, it may also allow the driver to return to the application even if the buffer object is still in use.
Note that these options are not mutually exclusive. You may for instance want to map a buffer object range as read-write and only update a sub-range of the mapping. MAP_UNSYNCHRONIZED_BIT will let you map the range without blocking while preserving the content of the range, which MAP_INVALIDATE_RANGE_BIT will not allow.
You can also use MAP_INVALIDATE_BUFFER_BIT which will behave like a BufferData(…, NULL). Drivers may have optimizations for this case, such as buffer object double-buffering, and return quickly from a subsequent MapBuffer command.