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

Reply via email to