Yeah, it seems most Interlocked functions are assumed to use full fences, like their Windows API equivalents. (That's why there are *Acquire, *Release, and *NoFence variants in the Windows API.) Same goes for volatile.
Changing it will probably affect performance negatively, but if it's for correctness, we have no choice. Could we also add the Acquire/Release/NoFence variants for our internal use? From: Mono-devel-list <[email protected]<mailto:[email protected]>> on behalf of Vlad Brezae via Mono-devel-list <[email protected]<mailto:[email protected]>> Reply-To: Vlad Brezae <[email protected]<mailto:[email protected]>> Date: Thursday, August 18, 2016 at 3:03 AM To: Alex Petersen <[email protected]<mailto:[email protected]>>, Marek Safar <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [Mono-dev] Atomic semantics with Interlocked Hello, Lately I've been investigating a thread pool related hang on arm64 which I tracked it down to some missing memory barriers. It seems that, although the documentation doesn't seem to imply memory fences for Interlocked functions, the thread pool MS code assumes it does. How should we proceed with the fix ? Get MS to follow their documentation in reference source and explicitly use a memory barrier where needed ? Add memory barriers explicitly on our own bcl ? Get the Interlocked icalls to do an additional memory barrier so we leave managed code intact ? Vlad
_______________________________________________ Mono-devel-list mailing list [email protected] http://lists.dot.net/mailman/listinfo/mono-devel-list
