summaryrefslogtreecommitdiffstats
path: root/src/testlib
diff options
context:
space:
mode:
authorMarc Mutz <marc.mutz@kdab.com>2019-06-24 09:41:07 +0200
committerMarc Mutz <marc.mutz@kdab.com>2019-08-05 19:30:37 +0000
commit787e498487831c55be89979824709622ba29f17c (patch)
tree94a4ec99c8815b88791f900deaa7361b00a4ad94 /src/testlib
parent64d949207686a0225a78de572548a5361e340ae3 (diff)
QMutexPool: fix memory order of atomic operations
The array of QAtomicPointer<QMutex> can be initialized using relaxed stores of nullptr, since nullptr is the whole data. But once we store an actual QMutex pointer in the array, we need to publish the indirect data thus created. We did this, with testAndSetRelease(); what was missing was a corresponding acquire fence on load, without which there is no happens-before relationship between the writes performed by the QMutex ctor and the reads performed by a subsequent mutex.lock(), say, on the same data. Fix by adding acquire fences to all loads. That includes the dtor, since mutexes may have been created in different threads, and never been imported into this_thread before the dtor is running. As a drive-by, return a new'ed QMutex that was successfully installed directly to the caller, without again going through a load-acquire. Fixes: QTBUG-59164 Change-Id: Ia25d205b1127c8c4de0979cef997d1a88123c5c3 Reviewed-by: David Faure <david.faure@kdab.com> Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> (cherry picked from commit 65b8f59e045bb41fef99b1a44f462115de65064a) (cherry picked from commit da38f0d691d9d7eacfac5fbcbd47b887bd59bd39)
Diffstat (limited to 'src/testlib')
0 files changed, 0 insertions, 0 deletions