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