08.12.2015 17:29, Jim Starkey wrote: > In virtual all cases involving updates of non-interlocked data structures, > the logic is -- and must be: > > for (;;) > { > <examine state making tentative decision and computer desired future > state> > > if (<state incompatible with operation>) > <punt> > > if (<interlocked compare and swap>) > <success -- break out of loop or whatever> > } > > About the only exceptions are interlocked increment and decrement for very > simple operations. Whether or not there actually is an > "interlocked or" primitive, it isn't useful because it tell you nothing about > the flag state before the operation. > > Maintaining non-interlocked data structures is the hardest part of software > engineering. Very few engineers can do it well. > Ironically, it is considered hard only by the folks proficient at it. > > I submit that Firebird would be well advised to restrict interlocked > primitives to interlocked increment, interlock decrement, and > interlocked compare and swap and to write all but the most trivial increment > and decrement as stylized interlock compare and swap loops.
Agree. And Firebird code is written in this way. Regards, Vlad ------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel