[ovs-dev] [PATCH] datapath-windows: Add Windows thread atomic APIs for x64 binaries.

Sorin Vinturis svinturis at cloudbasesolutions.com
Tue Mar 29 16:20:13 UTC 2016


Ben, ovs-atomic-msvc.h contains support for 8,16,32 and 64-bit arithmetic and logical operations.
Regarding 64-bit operations, like read and write, they are performed using specific 64-bit interlocked functions, i.e. InterlockedCompareExchange64 and, respectivelly, InterlockedOr64. Both functions are performed atomically.

All remaining 64-bit operations use, also, 64-bit interlocked functions, which are executed atomically, except for logical AND operation. For the latter operation, an intrinsic function is used, _InterlockedExchangeAdd64, which means that is a faster function built in to the compiler. More details about this is here: https://msdn.microsoft.com/ro-ro/library/26td21ds(v=vs.80).aspx.


-----Original Message-----
From: Ben Pfaff [mailto:blp at ovn.org] 
Sent: Tuesday, 29 March, 2016 00:25
To: Sorin Vinturis
Cc: Guru Shetty; dev at openvswitch.org
Subject: Re: [ovs-dev] [PATCH] datapath-windows: Add Windows thread atomic APIs for x64 binaries.

On Mon, Mar 28, 2016 at 09:11:24PM +0000, Sorin Vinturis wrote:
> Hi Guru,
> 
> I have verified the ovs-atomic-msvc.h header and all the defined 
> macros and functions have 32-bit and 64-bit correspondent. All 64-bit 
> macros use InterlockedXXX functions that are atomic:
> InterlockedExchangeNoFence64, InterlockedExchange64, 
> InterlockedCompareExchange64, _InterlockedExchangeAdd64, 
> InterlockedAnd64, InterlockedOr64, InterlockedXor64. I have ran 
> test-atomic.c unit tests, on both 32-bit and 64-bit platforms, and all 
> the tests are verified.
> 
> I also tested the 64-bit build on Hyper-V and it is stable.
> 
> Is there a reason why we should not use ovs-atomic-msvc APIs for 64-bit builds?

ovs-atomic-msvc.h seems pretty oriented toward a 32-bit build.  At least, I really doubt MSVC would break 64-bit reads and writes into two 32-bit reads and writes on 64-bit builds, which is what the code in the header currently assumes.  You don't want to update it to handle 64-bit builds differently?  I guess that these would be optimizations, but they seem straightforward.



More information about the dev mailing list