On Fri, 20 Jan 2012, Mouse wrote: > >> 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.
That's not what the manpage documenting BUS_SPACE_BARRIER_SYNC says. Read the manpage. Eduardo
