Background tasks serialization

Question

I've read through background tasks whitepaper and MSDN documentation discussing background tasks, but one thing is entirely unclear to me. From the documentation it is evident that background tasks run independently from the state of the process, possibly concurrently with that process, and, more importantly, concurrently with each other.

Let's say we have a scenario, where background task code is scheduling a few tile updates. That task is triggered by a few triggers, let's say a maintenance trigger, network state change trigger, and OnlineIdConnectedStateChange trigger. These triggers can trigger at the same time, spawning multiple *concurrent* task instances that have no means in place to synchronize between them - so they step on each other toes, overwriting each other changes, and tiles end up being a mess.

Did I miss something? What is the suggested mechanic/API to avoid races in background tasks?

Answer 1

It's difficult to envision a scenario where the tile become a mess because you're updating them via different mechanisms, because there's only so much stuff that goes into a tile.  What's scenario do you have where this would be an issue?

---

Matt Small - Microsoft Escalation Engineer - Forum Moderator
If my reply answers your question, please mark this post as answered.

NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

Answer 2

Scenario set up:

1. Background task is responsible for scheduling 5 tile updates, each displaying a "unread message header".

2. "Unread messages" are stored in app settings and are updated regularly by main process (when it is in foreground).

Scenario, in chronological order:

1. Maintenance trigger fires, background task starts and manages to post 2 out of 5 tile updates before being preempted;

2. Main application (in foreground) updates the list of "unread messages", changing all 5 of them, it then updates the tile appropriately;

3. task A gets CPU time, posting the remaining 3 tile updates it needed to do; overwriting fresh updates from application and leaving the tile in inconsistent state (2 updates from new batch, 3 updates from the old batch).