Re: kqueue LOR

On Tue, 12 Dec 2006, John Baldwin wrote:

> On Tuesday 12 December 2006 13:43, Suleiman Souhlal wrote:

>> Why is memory barrier usage not encouraged? As you said, they can be used to
>> reduce the number of atomic (LOCKed) operations, in some cases.
>> ...
>> Admittedly, they are harder to use than atomic operations, but it might
>> still worth having something similar.

How would MI code know when using memory barriers is good?  This is already
hard to know for atomic ops -- if there would more than a couple of atomic
ops then it is probably better to use 1 mutex lock/unlock and no atomic
ops, since this reduces the total number of atomic ops in most cases, but
it is hard for MI code to know how many "a couple" is.  (This also depends
on the SMP option -- without SMP, locking is automatic so atomic ops are
very fast but mutexes are still slow since they do a lot more than an
atomic op.)

> Memory barriers just specify ordering, they don't ensure a cache flush so
> another CPU reads up to date values.  You can use memory barriers in
> conjunction with atomic operations on a variable to ensure that you can
> safely read other variables (which is what locks do).  For example, in this

I thought that the acquire/release variants of atomic ops guarantee
this.  They seem to be documented to do this, while mutexes don't seem
to be documented to do this.  The MI (?) implementation of mutexes
depends on atomic_cmpset_{acq,rel}_ptr() doing this.

Bruc