A overview about the Threading model in windows store apps

1. Threading model in Windows Store
apps
Mirco Vanini
Microsoft® MVP Windows Embedded

2.  Why threads?
 Windows threading model
 Objects and threading – Marshaling
 Agile objects
 Thread pool threads
 Using the thread pool in Windows Runtime apps
Agenda

3.  Service connected world
 Responsive apps
 Touch-based experience
 Many cores
Why threads?

4.  Kernel threads
 Separate processes
 Brokers
 Async operations
How Windows parallelizes for you

5.  UI objects live in a UI thread
 Main UI thread lasts as long as app
 Most other objects can be used on any thread
 We pass out work to thread pool when needed
Windows threading model

6.  Windows objects follow natural and familiar object rules
 You control lifetime
 You can use them on threads you take them to
 Where you create them doesn’t constrain where you use or
delete them
 One of our biggest changes relative to COM
Windows threading model

7. Windows threading model
App
Windows
UI
Object
Main UI Thread
Windows
Object
Threadpool
App Code App Code App Code
Windows
Object

8.  Three main types of object
 Thread bound – works only on the thread where it was created – most UI
 Thread flexible – works on any thread, uses locking if needed to control
simultaneous access
 Brokered – out of process
 UI runs in single threaded environment that is not reentrant
(“Application STA”)
 Callbacks can only enter if they are related to an outgoing call
 Most non-UI runs in any thread
Windows threading model

9. Brokered Objects
RuntimeBroker.exe
Windows
Runtime Object
IInspectable
IUnknown
App
Projection
Proxy

10.  User interface has special threading needs
 Don’t want OK to be pressed during OnCancel
 UI objects are deliberately and naturally serialized
 Don’t do long running work on UI thread
 Instead, offload large work to thread pool with async object
UI threads

11.  Objects on UI threads generally don’t need locking to protect
themselves
 UI threads are not reentrant
 UI threads can’t call each other directly
 Rejected at call time in Windows 8.1
 Use dispatcher or async object to avoid
UI threads

12.  No long delays allowed on UI threads
 Most classic waiting primitives are inappropriate
 Windows will terminate unresponsive apps
 Instead, use UI-safe primitives
 C#: await
 C++: create_task
 JS: promise
UI threads

13.  App primary UI always launched on main UI thread
 Contract UI (e.g. Share) launched on separate UI thread
 Main UI thread used for global state
 Other UI threads for documents, contracts
 Main UI thread stays alive until app dies
Main UI thread

14.  XAML UI objects are thread-bound
 Use dispatcher to move UI work back to relevant UI thread
 Whole XAML tree must host on a single thread
 XAML events will be delivered on the UI thread
 Async operations started on XAML threads have results
delivered back on UI thread
 DirectX situation similar
XAML environment threading

15.  Basic WinRT protocols are threading-agnostic
 IUnknown, IInspectable manages the object and its interfaces
 WinRT protocols allow for some objects to have special
threading requirements
 WinRT captures all these concepts with marshaling
Objects and threading

16.  Marshaling allows an object to be used from another thread
or process
 Most WinRT objects do not require marshaling
 Even references to out-of-process objects (proxies) are agile
in WinRT
 Objects decide how they are marshaled
 IMarshal, INoMarshal control marshaling
Marshaling

17.  Agile objects are objects that can work in any thread of a
process without being marshalled
 Agile objects are simple to deal with
 Most WinRT objects are agile
 Out-of-process proxies are agile
 Agile objects do not die if their original host thread dies
Agile objects

18.  Apartments are a COM concept that group and control
thread and object lifetimes
 Apartments exist in WinRT but have been made largely
irrelevant by agility to reduce pain
 Three types in Windows Store apps
 Application single-threaded apartment (ASTA) – UI threads
 Multithreaded apartment (MTA) – Thread pool
 Neutral threaded apartment (NTA) – Used by WinRT to help inter-
process calls
Apartments

19.  Where long-running work is done
 Allocated, scaled and scheduled by the operating system
 WinRT async operations automatically happen here
 Always initialized for WinRT usage when created
 Objects may be called back on any thread
Thread pool threads

20.  Your app can use the thread pool to accomplish work
asynchronously in parallel threads
 The thread pool offers more control than the asynchronous
programming patterns
 Submit work items, control their priority, and cancel work items
 Schedule work items using timers and periodic timers
 Set aside resources for critical work items
 Run work items in response to named events and semaphores
Using the thread pool

21. Submitting a work item to
the thread pool
demo

22. Submit a work item using a
timer
demo

23. Create a periodic work
item
demo

24. Respond to named events
and semaphores
demo

25.  Use the thread pool to do parallel work in your app
 Use work items to accomplish extended tasks without blocking the UI thread
 Create work items that are short-lived and independent. Work items run
asynchronously and they can be submitted to the pool in any order from the
queue
 Dispatch updates to the UI thread with the Windows.UI.Core.CoreDispatcher
 Use ThreadPoolTimer.CreateTimer instead of the Sleep function
 Use the thread pool instead of creating your own thread management system.
The thread pool runs at the OS level with advanced capability and it is already
optimized
Using the thread pool – Do’s

26.  Don't create periodic timers with a period value of <1 millisecond (including 0).
This will cause the work item to behave as a single-shot timer
 Don't submit periodic work items that take longer to complete than the amount of
time you specified in the period parameter
 Don't do any extensive work in the UI dispatch handler. The handler provided to
the UI core dispatcher runs in the UI thread
 Don't try to send UI updates (other than toasts and notifications) from a work item
running in a background task. Instead, use background task progress and
completion handlers
 Don't try to create work item handlers that use the async keyword
Using the thread pool – Dont's

27.  WinRT designed to make threading natural, simple, and
familiar
 Don’t block the UI thread
 Use async for long running operations
 Use the thread pool to accomplish work asynchronously in
parallel threads
Recap

28. Q&A

29. Contact
feedback
10
Blog http://mircovanini.blogspot.com
Email info@proxsoft.it
Web www.proxsoft.it
Twitter@MircoVanini