Lidgren must be compiled for x64 in order to be thread-safe?

[dendriel]

Some old documentation* says that NetPeer/NetConnection public members are completely thread safe, but looks like this holds only if we build the library targeting x64 platforms. Nevertheless, there is no guideline instructing how to configure the library compilation relative to this matter.

Is this true? The library should be compiled in x64 to avoid concurrency problems? (this way, we ensure that write and read of properties up to 8 bytes are atomic, avoiding concurrency between writter and reader).

[*] https://github.com/lidgren/lidgren-network-gen3/blob/master/Lidgren.Network/Documentation/Improvements.txt

Regards,

[Skyppid]

Concurrency has nothing to do with architecture. If you're running into concurrency issues on 86x platforms then you will likely do so in x64. Behavior may differ because your CPUs are not the same and possible to schedule and run things differently. But ultimately you're not provided with thread-safety by just compiling it for another architecture.

If it says it's thread-safe, then the class should be. You should rather provide some details what you're actually facing there. What isn't working and how does it show? If the class IS thread-safe but you're still having threading issues, then you're doing something wrong obviously.

[forestrf]

@Skyppid It does matter. Atomic operation thread safety depend on the architecture: a read or write of 32 bits is atomic in both 32 and 64 bit cpus, but a read or write of 64 bits is only atomic in a 64 bit cpu. Another different thing is that there is no an alternative thread-safe code for the 32 bit cpus, but it could be added with conditionals

[dendriel]

Hello, Skyppid,

Thanks for your reply!

I understand that the concurrency problem I'm reporting here is related to atomic write/reads (i.e. race condition) of properties from NetPeer/NetConnection. To be more clear, who writes the properties is lidgren thread (while sending/receiving messages) and who reads them is the user thread (accessing statistics values).

Because there is no explicit mechanism (lock or interlock) to avoid accessing the same property by both threads at the same time (thus may causing the read value to be inconsistent in x86), I'm asking if Lidgren library is intended to run over x64 system to ensure atomicity up to 8 bytes properties (avoiding the reported problem).

To understand how this kind of concurrency has to do with architecture, please, refer to to these docs:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms684122%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 https://docs.microsoft.com/en-us/dotnet/standard/threading/interlocked-operations

Example: http://benbowen.blog/post/cmmics_iii/

Regards,

[Skyppid]

Sorry, my bad. I did not think about that the moment. You're of course right. But having it explained a bit more thoroughly also makes it understandable. With which properties do you experience this behavior? A possibility would be a memory barrier. This could very well be a problem in that situation.