Added details on IsGlobalModeEnabled to Hubs and Scopes docs (#11426)

Author: jamescrosswell

docs/platforms/dotnet/common/enriching-events/scopes/index.mdx

@@ -36,13 +36,20 @@ time to modify data stored on the scope. This is useful for doing things like
 
 <Alert>
 
-If you are very curious about how thread locality works: On platforms such as .NET
-or on Python 3.7 and later we will use "ambient data" to have either the hub flow
-with your code or the hub is already a singleton that internally manages the scope.
-
-Effectively this means that when you spawn a task in .NET and the execution flow is
-not suppressed all the context you have bound to the scope in Sentry will flow along.
-If however you suppress the flow, you get new scope data.
+If you are very curious about how thread locality works for scope data, in .NET there
+are two modes for managing "ambient data". Usuaully Sentry will automatically choose the
+most appropriate mode for your application type. However this can be overridden by
+setting [`SentryOptions.IsGlobalModeEnabled`](../../configuration/options/#is-global-mode-enabled) manually.
+
+If global mode is disabled (appropriate for most server based applications), the
+ambient scope data is stored as an `AsyncLocal` and so it will flow with the execution
+context. Stephen Toub's blog post on [ExecutionContext vs SynchronizationContext](https://devblogs.microsoft.com/pfxteam/executioncontext-vs-synchronizationcontext/)
+explains that concept in more detail.
+
+If global mode is enabled (appropriate for desktop applications), ambient scope data is
+stored as a Singleton and available globally. This means you can set context (such as
+the user logged into the application) once and it will be sent with all events, regardless
+of whether the event was captured on the UI thread or a background thread.
 
 </Alert>
 

docs/platforms/powershell/enriching-events/scopes/index.mdx

@@ -36,13 +36,20 @@ time to modify data stored on the scope. This is useful for doing things like
 
 <Alert>
 
-If you are very curious about how thread locality works: On platforms such as .NET
-or on Python 3.7 and later we will use "ambient data" to have either the hub flow
-with your code or the hub is already a singleton that internally manages the scope.
-
-Effectively this means that when you spawn a task in .NET and the execution flow is
-not suppressed all the context you have bound to the scope in Sentry will flow along.
-If however you suppress the flow, you get new scope data.
+If you are very curious about how thread locality works for scope data, in .NET there
+are two modes for managing "ambient data". Usuaully Sentry will automatically choose the
+most appropriate mode for your application type. However this can be overridden by
+setting [`SentryOptions.IsGlobalModeEnabled`](../../configuration/options/#is-global-mode-enabled) manually.
+
+If global mode is disabled (appropriate for most server based applications), the
+ambient scope data is stored as an `AsyncLocal` and so it will flow with the execution
+context. Stephen Toub's blog post on [ExecutionContext vs SynchronizationContext](https://devblogs.microsoft.com/pfxteam/executioncontext-vs-synchronizationcontext/)
+explains that concept in more detail.
+
+If global mode is enabled (appropriate for desktop applications), ambient scope data is
+stored as a Singleton and available globally. This means you can set context (such as
+the user logged into the application) once and it will be sent with all events, regardless
+of whether the event was captured on the UI thread or a background thread.
 
 </Alert>
 

docs/platforms/unity/enriching-events/scopes/index.mdx

@@ -35,13 +35,21 @@ time to modify data stored on the scope. This is useful for doing things like
 [modifying the context](../context/).
 
 <Alert>
-If you are very curious about how thread locality works: On platforms such as .NET
-or on Python 3.7 and later we will use "ambient data" to have either the hub flow
-with your code or the hub is already a singleton that internally manages the scope.
 
-Effectively this means that when you spawn a task in .NET and the execution flow is
-not suppressed all the context you have bound to the scope in Sentry will flow along.
-If however you suppress the flow, you get new scope data.
+If you are very curious about how thread locality works for scope data, in .NET there
+are two modes for managing "ambient data". Usuaully Sentry will automatically choose the
+most appropriate mode for your application type. However this can be overridden by
+setting [`SentryOptions.IsGlobalModeEnabled`](../../configuration/options/#is-global-mode-enabled) manually.
+
+If global mode is disabled (appropriate for most server based applications), the
+ambient scope data is stored as an `AsyncLocal` and so it will flow with the execution
+context. Stephen Toub's blog post on [ExecutionContext vs SynchronizationContext](https://devblogs.microsoft.com/pfxteam/executioncontext-vs-synchronizationcontext/)
+explains that concept in more detail.
+
+If global mode is enabled (appropriate for desktop applications), ambient scope data is
+stored as a Singleton and available globally. This means you can set context (such as
+the user logged into the application) once and it will be sent with all events, regardless
+of whether the event was captured on the UI thread or a background thread.
 
 </Alert>