Modernizing atomics

[Ashod Nakashian]

On Mon, Oct 26, 2015 at 2:21 PM, Norbert Thiebaud <nthiebaud at gmail.com>
wrote:

> On Mon, Oct 26, 2015 at 1:00 PM, Ashod Nakashian <ashnakash at gmail.com>
> wrote:
> > On Mon, Oct 26, 2015 at 1:35 PM, Norbert Thiebaud <nthiebaud at gmail.com>
> > wrote:
> >>
> >> On Mon, Oct 26, 2015 at 12:14 PM, Ashod Nakashian <ashnakash at gmail.com>
> >> wrote:
> >> > OSL provides atomic helpers (osl_atomic_xxx) in the form of a GNU
> >> > builtin
> >> > (where available) or a platform-specific implementation.
> >> >
> >> > Any reason for not using modern std::atomic (besides possible lack of
> >> > volunteers) ?
> >> >
> >> >
> >> > As a transitional phase, we can maintain the same interface but with
> >> > std:atomic as the implementation.
> >> >
> >> > Thoughts?
> >>
> >> osl atomic are c interface, used in c-source...
> >>
> > Thanks. Is there equivalent used in C++ ? (osl atomics only work for
> > sal_Int32 values, which is another potential issue for 64-bit
> portability.)
>
> the c++ code use these too.
>

Would there be support for using std::atomic in C++ code?

There is a case to be made in terms of performance if nothing else (in some
scenarios they are hotspots, according to my profiler).


>
> relying on atomic on 64 bits is going to be a problem as long as we
> support 32 bits OS.
>

I believe most modern hardware support atomic operations on wide words
(i.e. 64-bit even when running in 32-bit mode).


> and mostly these atomic are used to ref-count... and there is really
> no reasonable need to have 64 bits ref-count is there ?
>

True for ref-counting. Not so for compare-exchange obviously (but I don't
know if these are used and how much).

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20151026/d538bcb7/attachment.html>