Does CL_MAP_WRITE_INVALIDATE_REGION permit overlapping kernel execution on the same buffer?

Short answer

No. CL_MAP_WRITE_INVALIDATE_REGION is a performance hint about host-side intent ("I will overwrite the whole region, so don't bother fetching old contents"), not a synchronization or exclusivity primitive. The OpenCL specification (1.2 onward, where the flag exists) does not grant the host exclusive access to the buffer during a map, and it does not define an ordering between the mapped region and kernels that touch the same buffer. If a kernel reads or writes an overlapping region while the buffer is mapped, the behavior is undefined: one implementation may quietly preserve coherence, another may use the hint to skip coherence work entirely, and your pipeline corrupts data only on the second one.

Answering your three questions

1. Ordering or exclusivity guarantees

None beyond the normal command-queue rules. What the spec does guarantee is the usual mapping semantics: the map operation is ordered with respect to previously enqueued commands that use the same memory object, so a map will not observe a buffer state from before prior work on that object. What it does not do is lock the buffer against kernels enqueued later, or make concurrent overlap well-defined. The "invalidate" wording only licenses the implementation to skip reading stale contents into the host mapping; it says nothing about device-side access during the map window.

2. Is a blocking map sufficient?

A blocking map (blocking_map = CL_TRUE) is sufficient only for work already enqueued: it will not return until prior commands affecting the buffer have completed, so previously submitted kernels cannot overlap your host writes. It gives you no protection against kernels submitted after the map call. Those must not be enqueued until after clEnqueueUnmapMemObject — on an in-order queue, unmapping before enqueueing the next kernel is enough; on an out-of-order queue you would need event dependencies. So the safe pattern is:

// prior kernels already enqueued
void *p = clEnqueueMapBuffer(queue, buf, CL_TRUE,
    CL_MAP_WRITE_INVALIDATE_REGION, 0, size, 0, NULL, NULL, &err);
// host writes the full region
clEnqueueUnmapMemObject(queue, buf, p, 0, NULL, NULL);
// only now enqueue kernels that touch buf

With a non-blocking map (CL_FALSE) you must wait on the returned event (or call clFinish) before touching the pointer, otherwise the host may write while device work is still in flight — the most hazardous variant of this bug.

3. Detecting coherence-skipping implementations

There is no portable query for this. No device info flag exposes "we honor invalidate as a coherence skip," and empirical corruption testing is unreliable precisely because the behavior is undefined — a passing test only proves your current driver/hardware combo happened to stay coherent. The only portable stance is to treat any overlap as a bug regardless of observed behavior.

Practical verification

To confirm the blocking-map ordering on your platform, enqueue a long-running kernel writing the buffer, then issue a blocking map and time it (or use event profiling on the kernel and map). The map's start should follow the kernel's end. This verifies ordering of prior work — it does not, and cannot, verify safety of overlap, because no such safety exists to verify.

Recommendation

Structure the pipeline so the buffer is never mapped while kernels referencing it can execute: use the hint for what it is (avoiding read-back of dead data when you fully overwrite a region), and get your concurrency from double-buffering or sub-buffers with disjoint regions instead of overlapping access to one buffer.