Don't worry about transient compare-and-swap failures. If you do some
testing, you will find that read-read conflicts are common.
But I don't get the logic that saving 10 ns. is worth introducing a
bug. I suppose there are cases where you want to set a bit and don't
care whether it was already set are diminishingly small -- and
insignificant. In this case, which I believe involves setting a
shutdown bit, the thread wishing to set the bit would be well advised to
know whether the bit has already been set, meaning that a shutdown is
already in progress.
On 12/8/2015 10:47 AM, Dimitry Sibiryakov wrote:
> 08.12.2015 16:29, Jim Starkey wrote:
>> In virtual all cases involving updates of non-interlocked data structures,
>> the logic is --
>> and must be:
> Unfortunately, this logic doesn't work quite well for bit flags.
> Consider two threads, setting flags A and B respectively.
>
>> for (;;)
>> {
>> <examine state making tentative decision and computer desired
>> future state>
> Here thread 1 got value with both flags unset.
>
>> if (<state incompatible with operation>)
>> <punt>
> In meantime thread 2 set flag B.
>
>> if (<interlocked compare and swap>)
> Here thread 1 set the value with flag A set and flag B reset.
>
>> <success -- break out of loop or whatever>
> Check fail, but still flag B is not set until the next round. The window
> for races is
> small but still exists.
>
> For integer flags situation is better. If we want to set flag, we just do
>
> if (interlocked compare and swap)
> <failure -- someone already set the flag before us, abort the action>
>
> Still there is a hope that CPU manufacturers will someday implement
> atomic_fetch_and_or
> in hardware because it is engraved in C++11 standard.
Probably never -- they aren't necessary. Fetches are always atomic and
the others are easily emulated with load-link/store-conditional or
interlocked compare and swap.
The reason they won't is that highly efficient implementation of
interlocked instructions in a multi-core processor is complex. In the
bad old days, an interlocked instruction would force all caches to flush
dirty lines back to memory before executing the instruction. A much
better -- but at considerable cost in complexity -- is to probe other
processors caches for conflicts.
If it makes a rat's ass worth of difference, they probably will, but I
don't see any advantage in doing so.
>
------------------------------------------------------------------------------
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
