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
