Re: RFC: New bus_space routine: bus_space_sync

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> 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                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B