On Mon, Nov 26, 2012 at 6:05 PM, Larry Brasfield
<larry_brasfi...@iinet.com> wrote:
> Nico Williams emitted:
>
>> You keep saying that programmers don't understand "barriers".  You've
>> provided no evidence of this.  Meanwhile memory barriers are generally
>> well understood, and every programmer I know understands that a
>> "barrier" is a synchronization primitive that says that all operations
>> of a certain type will have completed prior to the barrier returning
>> control to its caller.
>
>
> Well, since you don't know me, this does not contradict you, but ...
>
> My understanding of a memory barrier, formed from close study of the need
> for them and some implementations, is that they cause a partial ordering of
> memory operations, such that all accesses instigated before the barrier is
> created occur before all accesses instigated after the barrier is created.
> This does not mean that the caller of a barrier-creating function (or the
> executor of a barrier-creating instruction) does not get control until all
> prior accesses have been "completed".  The "caller" may well continue
> executing instructions from cache, and other execution units may not be held
> up at all unless they instigate an "after" access.
>
> I will be happy to become differently educated on this subject. (perhaps via
> some evidence ;-)

That's fair, but the effect is still indistinguishable from from what
I wrote.  (Well, I suppose one has to be careful about the possibility
of a CPU with I/O ports writes to which are not included in the
concept of a memory barrier, but we have to simplify somewhere, and
the point is that barriers are a simple enough concept that we can
program with it, and this is all the more so in filesystems, where we
don't have to concern ourselves with the nuances of many different
CPUs.  There are nuances in filesystem barriers, particularly writes
to MAP_SHARED mmap()ed regions, but barriers don't create new problems
there.)

Nico
--
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to