Revert addition of volatile backing field to Agent.IsConfigured
See original GitHub issueThe 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.
Issue Analytics
- State:
- Created 4 years ago
- Comments:8 (8 by maintainers)
Top Results From Across the Web
Log input | Filebeat Reference [8.9]
This string can only refer to the agent name and version and the event timestamp; for access to dynamic fields, use output.elasticsearch.index or...
Read more >IP Addressing: DHCP Configuration Guide, Cisco IOS ...
By using option 82, the Cisco IOS DHCP relay agent can include additional information about itself when forwarding client-originated DHCP ...
Read more >BitLocker recovery guide - Windows Security
This article for IT professionals describes how to recover BitLocker keys from Active Directory Domain Services (AD DS).
Read more >VMware ESXi 7.0 Update 3l Release Notes
When you upgrade an ESXi host from a version earlier than 7.0 Update 1 to a later version, the fields Vpx.Vpxa.config.nfc.loglevel and ...
Read more >BitLocker Group Policy settings - Windows Security
This article for IT professionals describes the function, location, and effect of each Group Policy setting that is used to manage BitLocker ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I hope my last comment addressed your concerns and we can close this issue.
Thank you very much for that and we welcome community contributions.
ECMA-334 (5th Edition / December 2017) 8.10 Execution order
Regarding
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