>> Even if originally intended for something else, [...] > Why do you think BUS_SPACE_BARRIER_SYNC was intended for something > else ? I can't see how a write barrier that doesn't ensure the write > has reached the target (main or device memory) can be usefull.
I can't comment on why someone else thinks something. But barriers that have nothing to do with write completion to the target can still be useful. There are algorithms that don't require that writes complete on any particular schedule, but do require that _this_ write complete before _that_ one. When faced with write coalescing and reordering, a write barrier that does nothing but enforce ordering (in the sequence A-barrier-B, the barrier enforces the constraint that there is no time at which write B has completed but write A hasn't) can be useful. For example, the standard double-buffering trick of "write inactive copy, then write variable indicating which is the active copy" does not work if the indicator's write can complete before the (formerly-)inactive copy's writes complete - but, in many uses, there is no requirement that those writes, as a sequence, be pushed to their target at any particular time. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B