23.03.2016 16:59, Jim Starkey wrote: > 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.
There is not rush. But such changes better to do now, then at release candidate stage. > 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. Life is more complex than plain CAS. There is different memory ordering supported by hardware and one single CAS is not effective (at least). > 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. I prefer to have dependancy on standard feature than on 3rd party library or self-made macros... Regards, Vlad ------------------------------------------------------------------------------ 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
