Revert addition of volatile backing field to Agent.IsConfigured

The changes in elastic/apm-agent-dotnet#621 to add a volatile backing field to Agent.IsConfigured (on the basis of the two assignments in Agent.Setup being reordered by hardware optimisation) are likely unnecessary.

As stated here:

The x86-x64 processor will not reorder two writes

As for the JIT compiler, ordering is guaranteed on the x86-x64 processor as also mentioned in the aforementioned link:

the JIT compiler doesn’t need to use any special instructions on the x86-x64 to achieve volatile semantics

I suggest to simply revert the changes in this PR.

[SergeyKleyman]

I hope my last comment addressed your concerns and we can close this issue.

[SergeyKleyman]

Note that I am trying to help with Elastic APM code where it doesn’t materially affect my own project right now.

Thank you very much for that and we welcome community contributions.

refer directly to the latest ECMA C# spec as it currently stands

ECMA-334 (5th Edition / December 2017) 8.10 Execution order

The execution environment is free to change the order of execution of a C# program, subject to the following constraints: - The ordering of side effects is preserved with respect to volatile reads and writes

Regarding

such ordering considerations in terms of optimisation are typically not necessary in modern programming

I think the opposite is the case - it stems from the fact that CPU manufactures cannot improve performance by increasing CPUs frequency anymore and instead modern CPUs scale horizontally (by increasing number of cores). Herb Sutter’s article “The Free Lunch Is Over” gives detailed explanation on that point. This change, just as movement to distributed/microservices architecture, means that some of the burden is shifted to the application programmer unless you just don’t use threads like NodeJS or don’t share any data between threads like Rust/Kotlin Native or always use locks to ensure thread safety which, akin to distributed transactions, might introduce considerable performance overhead. I also recommend to watch the following 2 part presentation by Herb Sutter where he explains how thread safety and runtime environment’s memory model are related. It’s based on C++ atomics which are essentially the same thing as C# volatile.

https://www.youtube.com/watch?v=A8eCGOqgvH4 https://www.youtube.com/watch?v=KeLBd2EJLOU