Digest for comp.lang.c++@googlegroups.com - 2 updates in 1 topic

comp.lang.c++@googlegroups.com

Google Groups

Topic digest
View all topics

• c++11: what's the guard variable for static local variable initialization? - 2 Updates

c++11: what's the guard variable for static local variable initialization?

Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 27 12:24AM +0100 On Sat, 26 Oct 2019 15:43:35 -0700 (PDT)   > so can I understand it like this?:   > 1. the obj_guard get set in __cxa_guard_release(&obj_guard), this MUST (WHY?) happen after the initialize_the_object(). If not then we are facing the same problem in double-checking-lock: one thread holds the lock, and reorder the initialization and guard assignment, makes another thread waiting on line 1 incorrectly returns too eariler.   > 2.after the obj_guard has been set, even another thread can't immediately see this update, it just go inside the needless lock/unlock, and this only happens the first few times.   If you look at the code you will see that __cxa_guard_acquire() checks initializerHasRun() again after it has acquired the mutex. So all is fine - locking and then unlocking a mutex has acquire and release semantics and so forces an ordering, even in a case where a race has occurred with respect to the original check of initializerHasRun() outside the mutex.

Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 27 12:44AM +0100 On Sun, 27 Oct 2019 00:24:15 +0100 > semantics and so forces an ordering, even in a case where a race has > occurred with respect to the original check of initializerHasRun() > outside the mutex.   Actually on looking further at the code it does seem to suffer from the traditional double checked locking problem in that a second thread could assume initialization by the first thread before it has in fact occurred.   Presumably either there is something else which deals with that problem or the compiler, knowing its platform (which is presumably x86/64 in this case), has calculated that this cannot in practice occur with its total store ordering memory model.

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.