> This patch makes me uncomfortable. I understand what it intends to do,
> and the intent is not wrong, but we're again treating "volatile UINT32"
> as atomic, and non-reorderable against the
> InterlockedCompareExchange32(). This kind of "optimization" is what
> people write cautionary tales about, later. It would be nice to see a
> semi-formal *proof* that this cannot backfire.
Laszlo,
Thanks for the questions. I was OOO in the past 10 days for Chinese New Year.
From Chapter 9 "Multiple-Processor Management",
section 9.2.2 "Memory Ordering in P6 and More Recent Processor Families",
I read the following:
In a single-processor system for memory regions defined as write-back
cacheable,
the memory ordering model respects the following principles...:
* ...
* Reads or writes cannot be reordered with I/O instructions, locked
instructions, or serializing instructions.
So, it guarantees/proves "read of BspIndex" performs before
"InterlockedCompareExchange32()/lock comxchg".
I think that can resolve one of your concern regarding the "ordering".
I don't quite understand your concern regarding the "atomic".
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115585): https://edk2.groups.io/g/devel/message/115585
Mute This Topic: https://groups.io/mt/104094808/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
