>A volatile write operation prevents earlier memory operations on the thread from being reordered to occur after the volatile write. A volatile read operation prevents later memory operations on the thread from being reordered to occur before the volatile read
Looks like release/acquire to me? A total ordering would be sequential consistency.
"In C#, using the volatile modifier on a field guarantees that every access to that field is a volatile memory operation"
This makes it sound like you are right and the volatile keyword has the same behaviour as the Volatile class which explicitly says it has acquire-release ordering.
But that seems to contradict "The volatile keyword doesn't provide atomicity for operations other than assignment, doesn't prevent race conditions, and doesn't provide ordering guarantees for other memory operations." from the volatile keyword documentation?
I too interpretat those docs as contradictory, and I wonder if, like how Java 5 strengthened volatile semantics, this happened at some point in C# too and the docs weren't updated? Either way the specification, which the docs say is definitive, says it's acquire/release.
"When a field_declaration includes a volatile modifier, the fields introduced by that declaration are volatile fields. [...] For volatile fields, such reordering optimizations are restricted:
A read of a volatile field is called a volatile read. A volatile read has “acquire semantics”; that is, it is guaranteed to occur prior to any references to memory that occur after it in the instruction sequence.
A write of a volatile field is called a volatile write. A volatile write has “release semantics”; that is, it is guaranteed to happen after any memory references prior to the write instruction in the instruction sequence."
Acquire-release ordering provides ordering guarantees for all memory operations. If an acquire observes a releases, the thread is also guaranteed to see all the previous writes done by the other thread - regardless of the atomicity of those writes. (There still can't be any other data races though.)
This volatile keyword appears to only consider that specific memory location whereas the Volatile class seem to implement acquire-release.
Somewhat off topic, but what is a realistic example of where you need atomics with sequential consistency? Like, what useful data structure or pattern requires it? I feel like I've seen every other ordering except that one (and consume) in real world code.
A mutex would be the most trivial example. I don't believe that is possible to implement, in the general case, with only acquire-release.
Sequential consistency mostly become relevant when you have more than two threads interacting with both reads and writes. However, if you only have single-consumer (i.e. only one thread reading) or single-producer (i.e. only one thread writing) then the acquire-release semantics ends up becoming sequential since the single-consumer/producer implicitly enforces a sequential ordering. I can potentially see some multi-producer multi-consumer queues lock-free queues needing sequential atomics.
I think it's rare to see atomics with sequential consistency in practice since you typically either choose (1) a mutex to simplify the code at the expense of locking or (2) acquire-release (or weaker) to minimize the synchronization.
No, sorry. I was just remembering where I've typically seen sequential consistency being used. For instance, Peterson's algorithm was what I had in mind. Spinlock is indeed a good example (although a terrible algorithm which I hope you haven't seen used in practice) of a mutex algorithm which only requires acquire-release.
I don't think you can simply hand-wave the differences between your two parties. There do seem to be substantially different outcomes for the people affected by these issues.
One interesting usecase is that you can run a tauri app without any webview windows just as a system tray icon and only spawn a webview window when necessary.
This kind of makes it way more lightweight but only in some situations (obv. heavily depending on the functionality of the app).
Would this be for a service style app that happens to have a UI when you need to configure it? If so that's an... interesting idea, but considering the UI is less important I'd probably mind it less (as someone who is not a fan of Electron apps).
Nice catch! That warning definitely wasn't emitted the last time I tried this.. I don't know about using something like your suggestion which has actual side effects, but probably something like #![cfg_attr(invalid, allow(unused_attributes))] instead would work (without side effects).
It possible to disable this plugin. I have it disabled.[1]
The linked YouTrack thread[2] in the article says so as well. It is just not possible to remove the plugin entirely from your device.
Regarding the plugin being enabled by default the official response by Jetbrains says [3]
The AI Assistant plugin is enabled by default and menu items and tool windows are visible in the UI. However, AI Assistant functionality is NOT available by default, and NO requests are sent to the JetBrains AI Service unless ALL of the following conditions are met:
- The user has explicitly consented to use the AI Assistant and is using the trial or has purchased the corresponding subscription.
- The AI Assistant has not been disabled for a particular project.
- In the case of a commercial IDE license, the AI Assistant has to have been enabled at the organizational level. We’d like to reiterate that for commercial IDE licenses, unless this is explicitly enabled by your organization’s administrators, AI Assistant will not be available.
I'm not saying this is perfect and this can obviously still be a problem on e.g work devices.
On release, IIRC, disabling it did not work persistently, ostensibly due to a combination of bugs, so a lot of people found that especially egregious.
I think it was something like it would default to enabled again if you uninstalled the updated version, since you can't uninstall the bundled version? I don't quite recall.
"There is no guarantee of a single total ordering of volatile writes as seen from all threads of execution"
https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...