UWP App Service线程模型疑问：事件处理方法是否需同步？

Great question—this is a common point of confusion when working with UWP App Services, especially when pairing them with Edge extensions via native messaging. Let’s break this down clearly:

Core Thread Model Behavior #

First, the key detail: All UWP App Service event handlers (including OnBackgroundActivated, AppServiceConnection.RequestReceived, AppServiceConnection.Closed, etc.) are dispatched to the same background task thread's message loop by default. This means that under normal circumstances, only one event handler will execute at a time.

So if your event handlers are synchronous, or you use await with the default ConfigureAwait(true) (which brings execution back to the original context), you won’t have concurrent access to shared resources like your AppServiceConnections dictionary from these handlers.

Why the Official Example Uses Synchronization in OnBackgroundActivated #

The sample’s lock around dictionary access in OnBackgroundActivated is likely a defensive measure, or to account for edge cases:

• While OnBackgroundActivated is typically called once per App Service activation, there are rare scenarios where it might be re-triggered (e.g., if the background task is restarted unexpectedly).
• It sets a clear pattern for handling shared state, even if the immediate case doesn’t strictly require it.

When You Do Need Manual Synchronization #

You’ll need to implement your own synchronization (or use thread-safe collections) if:

• You explicitly offload work to another thread (e.g., using Task.Run, accessing the thread pool directly) within an event handler. This code will run concurrently with other event handlers.
• You modify shared state from outside the App Service’s event handler context (e.g., from another component of your UWP app).

Recommended Practice for Your Edge Extension Scenario #

For managing AppServiceConnection instances and their deferrals in an Edge extension native messaging setup:

• Use ConcurrentDictionary<TKey, TValue> instead of a regular Dictionary. This is a thread-safe collection that eliminates the need for explicit lock statements in most cases, even if you end up with concurrent access later.
• If you stick with a regular Dictionary, wrap all accesses (reads and writes) in a lock block—consistently across all methods that touch the dictionary, not just OnBackgroundActivated. This avoids subtle race conditions that might pop up as you extend your code.

Quick Recap #

• Default behavior: No concurrent execution of App Service event handlers (same thread context).
• Defensive approach: Use thread-safe collections or consistent locking to protect shared state, especially since it’s easy to introduce async/threaded code later without realizing it.

内容的提问来源于stack exchange，提问作者Alexey Sidorov