On 3/23/2016 5:04 AM, Vlad Khorsun wrote: > All, > > in new codebase (v4) we going to use atomic operations more intensively than > before. The question is: could we use standard features of C++11 or should > choose some 3rd party library (such as libatomic_ops) for it ? > > The main concern about C++11 atomics is - if all platforms where Firebird > can be built have support for it (by software and hardware) ? We have no > problem with Intel\AMD and Linux\Windows (GCC and MSVC supports C++11 atomics) > but i have no idea about MAC\HP\AIX\ARM and other... > >
What's the rush? You may find important compilers that don't support it or have garbage implementations. The reasonable way to handle atomics is for project defined macros on whatever facilities the various platforms expose. When I originally wrote SyncObject, I had to use in-line assemble everywhere. The Microsoft implemented satisfactory compiler intrinsics (OK, not strictly portable between 32 and 64 bits, but workable). Later, gcc got around to implementing compiler intrinsics and I was able to ditch the last remaining inline assembler. Lately, I was pleased to discovered that gcc on ARM supports the same intrinsic COMPARE_AND_SWAP even though the underlying hardware didn't. Defining your own macro layer gives you cheap portability and a zero overhead implementation. With C++11, you may be stuck with a high overhead library runtime call written by somebody who didn't really understand the hardware instructions, just like the rancid STL garbage for its first half dozen years. Personally, I haven't a clue what the original macros got replaced with template that called platform specific implementations. A macro would have compile as one or two machine instructions rather than a number of nested called. Strikes me as a way to introduce unnecessary complexity at a significant cost in performance. Personally, I'm quite happy with macros that hide platform differences. If I ever decide that I care about C++11 and its implementation is decent on the platform I care about, I'd redefine the macros to the new feature. But I wouldn't see any reason to change the existing code. Firebird 3 took (will take?) way too long to ship. One way to help streamline releases is to minimize unnecessary dependencies. Building a completely unnecessary dependency on C++11 may be one of the solutions to non-problems that will turn around and bite you. ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
