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

[Konstantin Belousov]

On Mon, Oct 29, 2012 at 08:53:07AM +0100, Andre Oppermann wrote:
> 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.
This is wrong, both for preassumption ('sched_pin() can only be used
within a critical section') and for the conclusion. sched_pin() does
not require the containing critical section for use.

sched_pin() is a thread-local operation. This is why we should only
worry about local reordering, since mi_switch() must be executed
by current processor to switch the current thread.

I agree with Attilio patch, it seems that normal C rules are not enough
to guarantee that no harmful reordering, which can be observed through
the async events on current core, happens.
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-projects/attachments/20121029/58af498e/attachment.sig>