-
Notifications
You must be signed in to change notification settings - Fork 3k
Use atomics for double-checked locks (SingletonPtr + __cxa_guard) #9530
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes looks good and now static
initialisation follows C++11 requirements.
Is there any argument still in favour of using SingletonPtr
over static
initialisation ?
Foo& getFoo {
static Foo foo;
return foo;
}
SingletonPtr<Foo> foo;
Not much, apart from its syntactic handiness. The If there was a way to achieve the syntactic handiness using a C++ Only other distinction is |
679affe
to
ad68d25
Compare
SingletonPtr's implementation wasn't totally safe - see "C++ and the Perils of Double-Checked Locking"by Meyers and Alexandrescu. No problems observed in practice, but it was potentially susceptible to compiler optimisation (or maybe even SMP issues). Now that we have atomic loads and stores, the function can be made safe, avoiding any potential races for threads that don't take the lock: ensure that the unlocked load is atomic, and that the pointer store is atomic. See https://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/ for more discussion.
ad68d25
to
7de71e8
Compare
Similar to SingletonPtr, use atomic accesses when loading the guard word outside the lock, and when storing, to ensure no races for threads that don't take the lock. Lack of atomics unlikely to be a problem in current builds, but code could conceivably be subject to reordering if link-time optimisation was enabled.
A couple of places in mbed_retarget.cpp were testing for either ARMC5 or ARMC6 in a long-winded fashion. Testing for __ARMCC_VERSION being defined is sufficient.
5514247
to
6e3c492
Compare
CI started |
Test run: SUCCESSSummary: 12 of 12 test jobs passed |
Description
Make SingletonPtr safe using atomics
SingletonPtr
's implementation wasn't totally safe - see "C++ and the Perils of Double-Checked Locking" by Meyers and Alexandrescu. No problems observed in practice, but it was potentially susceptible to compiler optimisation (or maybe even SMP issues).Now that we have atomic loads and stores, the function can be made safe, avoiding any potential races for threads that don't take the lock: ensure that the unlocked load is atomic, and that the pointer store is
atomic.
See https://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/ for more discussion.
Use atomics in __cxa_guard functions
Similar to
SingletonPtr
, use atomic accesses when loading the guard word outside the lock, and when storing, to ensure no races for threads that don't take the lock.Lack of atomics unlikely to be a problem in current builds, but code could conceivably be subject to reordering if link-time optimisation was enabled.
Pull request type
Reviewers
@pan-, @c1728p9