Re: Modernizing atomics

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

> On Mon, Oct 26, 2015 at 1:00 PM, Ashod Nakashian <ashnakash@gmail.com>
> wrote:
> > On Mon, Oct 26, 2015 at 1:35 PM, Norbert Thiebaud <nthiebaud@gmail.com>
> > wrote:
> > > On Mon, Oct 26, 2015 at 12:14 PM, Ashod Nakashian <ashnakash@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.