af95ec4b7b
On systems with weak memory ordering, it was possible for the storeRelaxed(Initialized) to be observed by another thread performing a loadRelaxed() without observing the contents of the object itself. The mutex *does* release the contents of the object to memory, but without the corresponding mutex acquisition, we couldn't guarantee that the object's contents would be observed. Now we can. We don't need to fix the load inside the mutex because the mutex will have acquired everything from either a previous call to pointer() or to reset(). The store inside reset() need not be storeRelease() either because the effect of observing the Uninitialized state will be to lock the mutex. None of this is used to protect the data as it is being mutated by the user in multiple threads, or their access simultaneously with reset() (which is why the load outside the mutex was removed). Thanks to litb on Slack for noticing this and bringing to my attention. Pick-to: 6.5 Change-Id: Idd5e1bb52be047d7b4fffffd1752df5b4d9b2e3f Reviewed-by: Marc Mutz <marc.mutz@qt.io> |
||
---|---|---|
.github/workflows | ||
bin | ||
cmake | ||
coin | ||
config.tests | ||
dist | ||
doc | ||
examples | ||
lib | ||
libexec | ||
LICENSES | ||
mkspecs | ||
qmake | ||
src | ||
tests | ||
util | ||
.cmake.conf | ||
.gitattributes | ||
.gitignore | ||
.lgtm.yml | ||
.tag | ||
CMakeLists.txt | ||
conanfile.py | ||
config_help.txt | ||
configure | ||
configure.bat | ||
configure.cmake | ||
dependencies.yaml | ||
qt_cmdline.cmake | ||
sync.profile |