Volatile in Wintun

* Volatile in Wintun
@ 2019-08-19  7:26 Lev Stipakov
  2019-08-19 18:15 ` Jason A. Donenfeld
  0 siblings, 1 reply; 4+ messages in thread
From: Lev Stipakov @ 2019-08-19  7:26 UTC (permalink / raw)
  To: wireguard

[-- Attachment #1.1: Type: text/plain, Size: 1261 bytes --]

Hi,

I am working on Wintun support for OpenVPN..

I am a bit unsure about the purpose of volatile in Wintun.

According to https://en.cppreference.com/w/cpp/atomic/memory_order,
volatile ensures that accesses are not reordered within the thread of
execution, but order is not guaranteed to be observed by another thread.

On the other hand, Visual Studio generates memory barriers while accessing
volatile objects and targeting non-ARM architectures
https://docs.microsoft.com/en-us/cpp/cpp/volatile-cpp?view=vs-2019#microsoft-specific.
However, it also says that "for architectures other than ARM we strongly
recommend that you specify /volatile:iso, and use explicit synchronization
primitives and compiler intrinsics when you are dealing with memory that is
shared across threads."

A few question I would like to ask:

- Is guarantee that accesses are not reordered within the thread of
execution is enough?

- Do we rely on Microsoft-specific behavior of volatile for non-ARM
architecture?

- Could reordering performed in ARM be a problem? If yes, shouldn't we
(wintun and client app) use memory fences to synchronize accesses between
threads? In openvpn3 we use C++11 so we were thinking about
std::atomic_long with acquire/release semantics.

-- 
-Lev

[-- Attachment #1.2: Type: text/html, Size: 1807 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 4+ messages in thread