summaryrefslogtreecommitdiff
path: root/offapi/com/sun/star/chart/ChartArea.idl
diff options
context:
space:
mode:
authorLuboš Luňák <l.lunak@collabora.com>2018-06-15 11:33:39 +0200
committerMichael Meeks <michael.meeks@collabora.com>2018-06-18 10:56:35 +0200
commitf6bd95704e46f53fd976519cc7d916f28a4ddc94 (patch)
treed88b54ac18ab0eeeda24b870dd808bf7d3533c0c /offapi/com/sun/star/chart/ChartArea.idl
parentfbe6fa330f8da3bc4c353d4e7adf85d1663ad7bc (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/star/chart/ChartArea.idl')
0 files changed, 0 insertions, 0 deletions