From 7819a911ff5132b34996c8b09b2a024cd10fd4fb Mon Sep 17 00:00:00 2001 From: Dimitry Andric Date: Sun, 20 Mar 2022 22:21:28 +0100 Subject: [PATCH] Merge libcxxrt commit f2e55091e2e878386c9f7974d4922bbdc4faed84 Fix unlock in two-word version and add missing comment. Fixes #15 Fixes #16 This should fix the hangs in __cxa_guard_acquire() reported on i386 (and possibly other 32-bit platforms). Obtained from: https://github.com/libcxxrt/libcxxrt/commit/f2e5509 Fixes: 56aaed388b0a MFC after: 2 weeks --- contrib/libcxxrt/guard.cc | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/contrib/libcxxrt/guard.cc b/contrib/libcxxrt/guard.cc index 515992563a10..cb58aa7da28e 100644 --- a/contrib/libcxxrt/guard.cc +++ b/contrib/libcxxrt/guard.cc @@ -69,7 +69,12 @@ * progress). The bit to use depends on the byte order of the target. * * On many 32-bit platforms, 64-bit atomics are unavailable (or slow) and so we - * treat the two halves of the 64-bit word as independent values and + * treat the two halves of the 64-bit word as independent values and establish + * an ordering on them such that the guard word is never modified unless the + * lock word is in the locked state. This means that we can do double-checked + * locking by loading the guard word and, if it is not initialised, trying to + * transition the lock word from the unlocked to locked state, and then + * manipulate the guard word. */ namespace { @@ -227,7 +232,7 @@ namespace // If another thread did manage to initialise this, release // the lock and notify the caller that initialisation is // done. - lock_word.store(initialised, memory_order::release); + lock_word.store(0, memory_order::release); return GuardState::InitDone; } return GuardState::InitLockSucceeded;