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 ;-)
Cheers,
--
Larry Brasfield
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
