Re: [ros-dev] [ros-diffs] [pschweitzer] 52065: [NTOSKRNL] - renamed Io volumes g

[Timo Kreuzer]

Am 03.06.2011 17:55, schrieb Alex Ionescu:
>   While the paper on Linux's spinlock semantics was
> very interesting, it remains the fact that this is not the case in Windows in this
> particular instance.
>
>  A lot of ReactOS code *is* missing calls such as KeMemoryBarrier() and (volatile), and
> only works by chance, so the argument that "otherwise our code wouldn't
> work" is a bit of a fallacy.
>
>  You also need to think outside the strict-ordering x86 box. Most of ReactOS' code is
> totally borked on IA64, PPC or ARM (and semi-broken on x64 too, which has looser
> ordering).
>
>  Of course, feel free to ignore the suggestion.
>
>  --
>  Best regards,
>  Alex Ionescu
>  
I won't ignore the suggestion. I'd rather try to convince you that its 
useless.
Lets look at this particular instance.

     Irql = KeAcquireQueuedSpinLock(Queue);
     OldValue = (*Ulong)--;
     KeReleaseQueuedSpinLock(Queue, Irql);

KeAcquireQueuedSpinLock is declared as:

_DECL_HAL_KE_IMPORT
KIRQL
FASTCALL
KeAcquireQueuedSpinLock(
   IN OUT KSPIN_LOCK_QUEUE_NUMBER Number);

Thats really all we need to know. Its a fastcall function. Its not 
inline, but a function calls across the translation unit boundaries. 
This alone is enough to guarantee strict compiler ordering of memory 
accesses around the bounds of the call.
The compiler cannot know what will happen inside the function that is 
being called, so it won't make any assumptions about reordering 
possibilities.

See:
http://publications.gbdirect.co.uk/c_book/chapter8/sequence_points.html

MSDN: http://msdn.microsoft.com/en-us/library/d45c7a5d%28VS.80%29.aspx
"Function-call operator. The function-call expression and all arguments 
to a function, including default arguments, are evaluated/*and all side 
effects completed*/ prior to entry to the function. There is no 
specified order of evaluation among the arguments or the function-call 
expression."

Also described in the ansi-C standard, but pretty abstract:
http://www.bsb.me.uk/ansi-c/ansi-c-one-file#sec_2_1_2_3
http://www.bsb.me.uk/ansi-c/ansi-c-one-file#sec_3_3_2_2

Regards,
Timo