diff options
author | Luboš Luňák <l.lunak@collabora.com> | 2018-06-15 11:33:39 +0200 |
---|---|---|
committer | Michael Meeks <michael.meeks@collabora.com> | 2018-06-18 10:56:35 +0200 |
commit | f6bd95704e46f53fd976519cc7d916f28a4ddc94 (patch) | |
tree | d88b54ac18ab0eeeda24b870dd808bf7d3533c0c /offapi/com/sun | |
parent | fbe6fa330f8da3bc4c353d4e7adf85d1663ad7bc (diff) |
use std::atomic rather than OSL_DOUBLE_CHECKED_LOCKING_MEMORY_BARRIER
Sources such as
http://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/
or https://en.wikipedia.org/wiki/Double-checked_locking suggest that
it wasn't possible to reliably do a portable double-checked initialization
before C++11. It may be true that for all platforms we support those
memory barriers are in fact not needed (which seems to be the assumption
behind OSL_DOUBLE_CHECKED_LOCKING_MEMORY_BARRIER being empty), and
looking at the generated assembly here on x86-64 seems to confirm that, but
in the worst case then this is a more chatty and standard way of writing
a no-op.
I don't want to use threadsafe statics or std::call_once() because
ScGlobal::Clear() does cleanup, which would be non-trivial to do with these,
and also some functions may not necessarily always force
creation of the singleton when touching the pointer, so it can't be easily
hidden behind a single function call.
The need to explicitly use load() with delete (thus preventing DELETEZ)
looks like a Clang bug to me.
Change-Id: Id3b0ef4b273ed25a5c154f90cde090ea1f9674fb
Reviewed-on: https://gerrit.libreoffice.org/55851
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Diffstat (limited to 'offapi/com/sun')
0 files changed, 0 insertions, 0 deletions