On Mon, Oct 26, 2015 at 2:21 PM, Norbert Thiebaud <nthieb...@gmail.com> wrote:
> On Mon, Oct 26, 2015 at 1:00 PM, Ashod Nakashian <ashnak...@gmail.com> > wrote: > > On Mon, Oct 26, 2015 at 1:35 PM, Norbert Thiebaud <nthieb...@gmail.com> > > wrote: > >> > >> On Mon, Oct 26, 2015 at 12:14 PM, Ashod Nakashian <ashnak...@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.
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
