diff options
| author | Marc Mutz <marc.mutz@kdab.com> | 2019-06-26 07:24:18 +0200 |
|---|---|---|
| committer | Marc Mutz <marc.mutz@kdab.com> | 2019-06-27 20:00:14 +0200 |
| commit | 6fa34930c23c7494a3f2703777f46794ff091e2b (patch) | |
| tree | f09074edc288b08c44d029d60f7840781cde1dbc /src/corelib/tools | |
| parent | 09075b40e9958f1945bca60a8c449869e32983b4 (diff) | |
QFreeList: fix memory order on block deletion
Blocks are likely to have been created in a differnt thread from the one
performing their deletion, so we need an acquire fence.
The rest of the atomics use in the class looks ok, but nevertheless warrants
a deeper analysis.
Change-Id: I1571ded3a06695b0d58b5bf1d80d6283ac21f959
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Diffstat (limited to 'src/corelib/tools')
| -rw-r--r-- | src/corelib/tools/qfreelist_p.h | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/corelib/tools/qfreelist_p.h b/src/corelib/tools/qfreelist_p.h index dcaf5688dc..5ba23b344b 100644 --- a/src/corelib/tools/qfreelist_p.h +++ b/src/corelib/tools/qfreelist_p.h @@ -218,7 +218,7 @@ template <typename T, typename ConstantsType> inline QFreeList<T, ConstantsType>::~QFreeList() { for (int i = 0; i < ConstantsType::BlockCount; ++i) - delete [] _v[i].loadRelaxed(); + delete [] _v[i].loadAcquire(); } template <typename T, typename ConstantsType> |