On 28 March 2017 at 19:21, yoann padioleau <aryx.padator@gmail.com> wrote:

> For example I see this code in bcm/taslock.c
>
>         coherence();
>         l->key = 0;
>         coherence();
>
> bcm/taslock.c seems actually mostly a copy paste of port/taslock.c
> with an extra call to coherence before the assignment above.
>

I've got that extra coherence call in port/taslock.c now (although my more
recent kernels use MCS locks exclusively)

You need to look at the full code fragment:

l->p = nil;
l->pc = 0;
l->m = nil;
coherence();
l->key = 0;
coherence();

assume coherence is a suitable barrier instruction on a given machine.
the calls are there to control the ordering (of stores in this case) as
seen by an observer,
which depends on the memory ordering model of a given processor or system
implementation.

the sequence is clearing references in the lock, to the Proc and the Mach
on which it's running.
we don't care about the order in which those stores are observed.
the first barrier ensures that all are observable before the critical store
to key that releases the Lock.

the second barrier ensures that once the lock is free, no further store can
be observed before
the lock-clearing store has been observed.

there is a general assumption in the system that any multiprocessor running
these kernels will have cache-coherency enabled across processors, although
that need not extend to devices (where the device drivers can do the little
dances needed to ensure coherent views of memory).