Original contribution

Author: carrollj

tutorials/scripting/c_sharp/c_sharp_basics.rst

@@ -393,16 +393,20 @@ Using ``async``/``await``
 -------------------------
 
 You might face a scenario where you must ``await`` a method call.
-You will notice that when you use ``await``, you are required to mark the method you use it in as ``async``, and change the return type to ``Task`` or ``Task<T>``. 
-Consequently, you must call your now ``async`` method using ``await``, which propogates the problem all the way up the call chain.
-This is why many people compare ``async``/``await`` to a "zombie virus", because it tends to spread once introduced.
+You will notice that when you use ``await``, you are required to mark the method you use it in as ``async``, 
+and change the return type to an awaitable type, such as ``Task`` or ``Task<T>``. 
+Consequently, you must call your now ``async`` method using ``await``, 
+which propagates the problem all the way up the call chain.
+This is why many people compare ``async``/``await`` to a "zombie virus", 
+because it tends to spread once introduced.
 
 In Godot, the conclusion to this spread is the entry point methods of a node, such as ``_Ready()`` or ``_Process()``.
 You will notice that the return types of these methods are ``void`` rather than ``Task``.
 It is considered conventional wisdom in C# to avoid ``async void`` at all times, with the exception of event handlers.
 The problem is that it is impossible to change the signatures of these methods since they are defined by the classes they inherit.
 
-There are a couple options to address this problem, but each option comes with its own caveats and considerations. To compare these options, we will work with the following script:
+There are a couple options to address this problem, but each option comes with its own caveats and considerations. 
+To compare these options, we will work with the following script:
 
 .. code-block:: csharp
 
@@ -412,8 +416,8 @@ There are a couple options to address this problem, but each option comes with i
 
     public partial class AsyncTestNode : Node
     {
-        int _taskCount = 0;
-        DateTime start;
+        private int _taskCount = 0;
+        private DateTime start;
         public override void _Ready()
         {
             start = DateTime.Now;
@@ -484,7 +488,10 @@ The second option is to mark the entry point method as async anyway.
             await DoStuffAsync(.5, nameof(_Process));
     }
 
-Both the manual task starting method and the ``async void`` method behave identically to an equivalent script written in GDScript that uses its version of the ``await`` keyword; the method pauses once it reaches the ``await``ed method call.
+Both the manual task starting method and the ``async void`` method 
+behave identically to an equivalent script written in GDScript 
+that uses its version of the ``await`` keyword; 
+the method pauses once it reaches the ``await``-ed method call.
 The game loop will run until the task completes, at which point execution will continue on the main thread.
 
 Let's look at the output from the above code:
@@ -498,10 +505,14 @@ Let's look at the output from the above code:
     00:00.53	Thread: 1	Task 2 completed
     00:00.53	Thread: 1	Task 3 completed
 
-The first observation from the output is that the game loop continues without waiting for the completion of the ``_Ready()`` method. 
-This continuation can introduce issues, especially if methods like ``_Process()`` rely on variables or objects that get initialized only after the ``await`` call in ``_Ready()``.
-Such asynchronous timing problems are termed `Race Condition <https://en.wikipedia.org/wiki/Race_condition#In_software/>`_, which is one of the main hazards when working with asynchronous code.
-To avoid errors due to race conditions, be sure to check that values are initialized before you use them, and use ``IsInstanceValid()`` after ``await``ing a function.
+The first observation from the output is that the game loop continues 
+without waiting for the completion of the ``_Ready()`` method. 
+This continuation can introduce issues, especially if methods like ``_Process()`` 
+rely on variables or objects that get initialized only after the ``await`` call in ``_Ready()``.
+Such asynchronous timing problems are termed `Race Condition <https://en.wikipedia.org/wiki/Race_condition#In_software/>`_, 
+which is one of the main hazards when working with asynchronous code.
+To avoid errors due to race conditions, be sure to check that values are initialized before you use them, 
+and use ``IsInstanceValid()`` after you ``await`` a function.
 
 Here is a pattern you can adopt to avoid race conditions:
 
@@ -513,8 +524,8 @@ Here is a pattern you can adopt to avoid race conditions:
         [Export] public int EntityID { get; set; } = 1;
     
         readonly SomeCustomRepository _db = new();
-        int _health;
-        bool _init;
+        private int _health;
+        private bool _init;
     
         // We will check IsInvalid after we await async methods
         // Otherwise we risk the continuation running in a disposed context
@@ -569,7 +580,8 @@ Here is a pattern you can adopt to avoid race conditions:
     }
 
 The third option is to execute the ``async`` method synchronously. 
-This is most commonly done when you need to use an asynchronous method from a third party library that has no synchronous equivalent, 
+This is most commonly done when you need to use an asynchronous 
+method from a third party library that has no synchronous equivalent, 
 and it is not feasible to convert everything upstream to ``async``.
 
 .. code-block:: csharp
@@ -598,7 +610,12 @@ Let's look at the output from the above code:
     00:01.03	Thread: 4	Task 3 started from _Process
     00:01.53	Thread: 4	Task 3 completed
 
-The output from running the tasks synchronously shows that the tasks executed in the expected order for synchronous operations. 
-The output also shows that the code was executed on Thread 4, rather than Thread 1 like in the first two options.
-This is important to keep in mind, because any code that is not executed on the main thread (Thread 1) cannot interact with the scene tree, as it is not thread safe.
-You should use ``CallDeferred``/``SetDeferred``, ``CallThreadSafe``/``SetThreadSafe``, or ``CallDeferredThreadGroup``/``SetDeferredThreadGroup`` to interact with thread safe objects or APIs from threads other than the main thread.
+The output from running the tasks synchronously shows that 
+the tasks executed in the expected order for synchronous operations. 
+The output also shows that the code was executed on Thread 4, 
+rather than Thread 1 like in the first two options.
+This is important to keep in mind, because any code that is not 
+executed on the main thread (Thread 1) cannot interact with the scene tree, as it is not thread safe.
+You should use ``CallDeferred``/``SetDeferred``, ``CallThreadSafe``/``SetThreadSafe``, 
+or ``CallDeferredThreadGroup``/``SetDeferredThreadGroup`` to interact with thread 
+safe objects or APIs from threads other than the main thread.