svn commit: r238907 - projects/calloutng/sys/kern

[Andre Oppermann]

On 29.10.2012 03:25, Adrian Chadd wrote:
> So colour me a bit silly, but why didn't you use an atomic here for
> that single variable, rather than a memory barrier alone?

Because sched_pin() can only be used within a critical section and
thus guarantees that we stay on the same CPU.  So we don't have to
worry about full SMP visibility and preventing just the compiler from
reordering or register caching the value.

The atomic functions do a full bus lock cycle and a CPU pipeline
flush (in most cases) to make sure that the new value is seen on
all CPU's at the same time.

On SMP architectures and shared data structures you have to worry
about three things:
  - compiler reordering (instruction optimizations)
  - cpu pipelines
  - memory and cache coherency

To be honest it takes some time to understand the different behaviors
and then to be able to reason about it.  There is quite some nice and
dense literature out there about atomics.  Googling turns up the
important ones.

> I feel slightly nitpicky about it, but this stuff rubs me up slightly
> the wrong way, same as the "don't worry about using atomics for 32 bit
> set/reads, as those are guaranteed to be atomic on all of the
> platforms we use" done what, last year or so.

Well, we have to have a baseline somewhere.  Many architectures don't
even have atomics for less than 32 bits.

-- 
Andre