I don't understand how the example shows the use or meaning of volatile. If I run it with or without volatile I'm getting the exact same results.
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
Thanks for your feedback @DavidMeerkatRefaeli. @BillWagner can you take a look at this issue when you're back?
@DavidMeerkatRefaeli What information are you looking for? Is it whether you should use the volatile keyword on a field? Is it how this affects access? Performance implications?
(It's difficult to make a good example for volatile that demonstrates different behavior consistently. The sample would need to have multiple threads, and create a thread switch at the right time to invoke a read in another thread of stale data.)
@BillWagner Maybe just add clarification that without the volatile, the worker thread will run a few more times the while-loop with the Console.WriteLine("Worker thread: working..."); because of stale data, before finally updating its cache (if I understand correctly how volatile works). Where as - with volatile it will exit the loop immediately as the field is changed.
@DavidMeerkatRefaeli I only have a very limited understanding of volatile but I don't think this would help that much. If you read through this StackOverflow question and the article from Eric Lippert linked there it becomes clear that the behavior of volatile can change depending on the runtime and even on the CPU. Related issue, where the wording that was questioned on StackOverflow was changed: #5206
In my opinion the sample should just be removed if it isn't possible to write a sample that shows the behavior on all runtimes and systems.
In my opinion the sample should just be removed if it isn't possible to write a sample that shows the behavior on all runtimes and systems.
I'm leaning toward keeping a simple sample that explains the syntax, even though the behavior is not easy to show in a small sample.
Hopefully I'm not too late but there's an example where volatile makes a difference (the last time I tested with x64 Release .NET Framework anyway) at http://benbowen.blog/post/cmmics_iii/variable_caching_example.html
The loop can fail to terminate at all if cancelLoop is not marked volatile.
@Xenoprimate I used your sample code on .NET Core and .NET Framework on a PC (64 bit) and .NET Core on Mac. It ran to completion in all cases, with or without the volatile keyword.
I still think the right answer is to remove the sample.
@BillWagner I think unfortunately that's the nefarious nature of multithreading issues. Especially with something like volatile it's basically a gamble each time whether or not your failure condition will show up; and may depend on the platform, build type, cpu architecture, time of day, number of butterflies nearby...
I still think having a small example of a case where volatile makes a difference would be useful; but maybe coupled with a noticable disclaimer along the lines of "Multithreading issues can be hard to replicate. The example given above may appear to work correctly even though it is technically buggy code; and subsequent executions may suddenly fail even if they previously ran to completion".
🤷♂️
Most helpful comment
@DavidMeerkatRefaeli I only have a very limited understanding of
volatilebut I don't think this would help that much. If you read through this StackOverflow question and the article from Eric Lippert linked there it becomes clear that the behavior ofvolatilecan change depending on the runtime and even on the CPU. Related issue, where the wording that was questioned on StackOverflow was changed: #5206In my opinion the sample should just be removed if it isn't possible to write a sample that shows the behavior on all runtimes and systems.