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

[Andre Oppermann]

On 29.10.2012 14:26, Konstantin Belousov wrote:
> 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 wasn't aware of these intimate dependencies and constrains.
Thanks for explaining it.

The lack of SMP visibility was the important part wrt. atomic ops.

-- 
Andre