Feb 10, 2016
Windows Runtime internals: Understanding the threading modelMartyn LovellDevelopment Manager, Windows Runtime Experience4-107
Why threading mattersThe WinRT threading modelWhat’s behind the curtain
Agenda
www.buildwindows.com
Demo: Why threading matters
www.buildwindows.com
Why threads?Service connected worldResponsive appsTouch-based experienceMany cores
www.buildwindows.com
How Windows parallelizes for youKernel threadsSeparate processesBrokersAsync operations
The view from the outside…
www.buildwindows.com
Windows threading modelUI objects live in a UI threadMain UI thread lasts as long as appMost other objects can be used on any threadWe pass out work to thread pool when needed
www.buildwindows.com
Windows threading modelWindows objects follow natural and familiar object rulesYou control lifetimeYou can use them on threads you take them toWhere you create them doesn’t constrain where you use or delete themOne of our biggest changes relative to COM
www.buildwindows.com
AppThreading
Windows UI
object
Main UI thread
Windows
object
Thread pool
App code App code App code
Windows
object
www.buildwindows.com
UI threadsUser interface has special threading needsDon’t want OK to be pressed during OnCancelUI objects are deliberately and naturally serializedDon’t do long running work on UI threadInstead, offload large work to thread pool with async object
www.buildwindows.com
Demo: UI Thread Behaviour
www.buildwindows.com
UI threads: reentrancyObjects on UI threads generally don’t need locking to protect themselvesUI threads are not reentrant:When you make a call to another thread/process, only logically connected threads can call back to you
www.buildwindows.com
Desktop STA thread
Dispatch call 1
Single-threaded apartment reentrancy
Outgoing call
Processing input and calls
Dispatch call 2
Processing input and calls
www.buildwindows.comASTA thread
Dispatch call 1
Windows Store App STA – no reentrancy
Outgoing call
Outgoing callcompletes
Call 1 completes
Processing input and all calls
Processing input and related calls
www.buildwindows.comASTA thread
Dispatch call 1
Windows Store App STA – no reentrancy
Outgoing call
Outgoing call completes
Call 1 completes
Dispatch call 2 Outgoing call
Outgoing call completes
Call 2 completes
Processing input and related calls
Processing input and all calls
Processing input and related calls
Processing input and all calls
Related callback
Call 2 waiting
www.buildwindows.com
ASTA thread
Cross-ASTA deadlock prevention
X
ASTA thread
X
www.buildwindows.com
UI threads: reentrancyUI threads can’t call each other directlyRejected at call time in Windows 8.1Use dispatcher or async object to avoidEnsures one UI thread can wait appropriately for the other to be readySee the MultipleViews sample for code showing how
www.buildwindows.com
UI threads: waitingNo long delays allowed on UI threadsMost classic waiting primitives are inappropriateWindows will terminate unresponsive appsInstead, use UI-safe primitivesC#: awaitC++: create_taskJS: promise
www.buildwindows.com
Demo: Safe View Shutdown
www.buildwindows.com
Main UI threadApp primary UI always launched on main UI threadContract UI (e.g. Share) launched on separate UI threadMain UI thread used for global stateOther UI threads for documents, contractsMain UI thread stays alive until app dies
www.buildwindows.com
HTML environment threadingAll threads are UI threadsEven web workers are single-threaded entitiesAll events, completions delivered where they startedUse standard web app model APIs instead of WinRT Core*Underlying process has full WinRT features
www.buildwindows.com
XAML environment threadingXAML UI objects are thread-boundUse dispatcher to move UI work back to relevant UI threadWhole XAML tree must host on a single threadXAML events will be delivered on the UI threadAsync operations started on XAML threads have results delivered back on UI threadDirectX situation similar
What’s behind the curtain…
www.buildwindows.com
Objects and threadingBasic WinRT protocols are threading-agnosticIUnknown, IInspectable manages the object and its interfacesWinRT protocols allow for some objects to have special threading requirementsWinRT captures all these concepts with marshaling
www.buildwindows.com
MarshalingMarshaling allows an object to be used from another thread or process. Most WinRT objects do not require marshalingEven references to out-of-process objects (proxies) are agile in WinRTSo while marshaling still exists it is rarely visible – deliberately!
www.buildwindows.com
MarshalingObjects decide how they are marshaledIMarshal, INoMarshal control marshaling WinRT objects generally opt out of marshalingEither UI based or agile and thus not marshaledAll marshalers provided by the operating system with the help of MIDL-generated data
www.buildwindows.com
MarshalingWhen will you need marshalingPassing types to UI threads – including dispatcher, JavaScriptTo make UI thread calls serialized, they must be queued and thus marshaledIf you define your own object and call from thread pool to UI, then you may need marshalingTo marshal, you need a proxy.
www.buildwindows.com
Thread pool threadsWhere long-running work is doneAllocated, scaled and scheduled by the operating systemWinRT async operations automatically happen hereAlways initialized for WinRT usage when createdObjects may be called back on any thread
www.buildwindows.com
ASTA thread
Async object callbacks
Thread pool thread
Async op start
Real work
Async complete delivery
Projection returns to ASTA thread
www.buildwindows.com
Thread Pool thread
Async object callbacks
Thread pool thread
Async op start
Real work
Async complete delivery
Completion delivered where work was done
www.buildwindows.com
Agile objectsAgile objects are objects that can work in any thread of a process without being marshalledAgile objects can only store agile thingsNo storing bare IInspectablesIf passed an IInspectable, must wrap it in an agile reference
www.buildwindows.com
Agile objectsAgile objects are simple to deal withMost WinRT objects are agileOut-of-process proxies are agileAgile objects do not die if their original host thread dies
www.buildwindows.com
Agile referencesWhen you get an IInspectable it may not be IAgileObjectIf it is not agile, may want to store an agile referenceNew for Windows 8.1: IAgileReference/RoGetAgileReferenceIf you are implementing an event source, you may need an array of agile references to event listeners
www.buildwindows.com
ApartmentsApartments are a COM concept that group and control thread and object lifetimesApartments exist in WinRT but have been made largely irrelevant by agility to reduce painThree types in Windows Store appsApplication single-threaded apartment (ASTA) – UI threadsMultithreaded apartment (MTA) – Thread poolNeutral threaded apartment (NTA) – Used by WinRT to help inter-process calls
www.buildwindows.com
Object lifetime & threadsObject lifetime in WinRT is simpleCOM would early-terminate objects, proxies, and agile references when apartment shut downWinRT makes most entities agile, lets you control lifetime
www.buildwindows.com
Cross-thread callingWinRT calls delivered only when thread is readyCalls compete with other items for a thread’s attentionWindows 8.1 changesCalls no longer block input deliveryScheduler allows prioritization of work items
www.buildwindows.com
SummaryWinRT designed to make threading natural, simple, and familiarWe’ve drilled below what you need to knowKey design points are simpleUse async for long running operationsChoose agile objects for all except UIDon’t block the UI threadSee Talk 3-136 for async debugging support
www.buildwindows.com
Threading model registrationWinRT objects must register their threading typeIt indicates where an activation occurs:SingleThreaded (value == 1) means always in a UI thread MultiThreaded (value == 2) means always in the thread poolBoth (value == 0) means 'in the apartment of the caller'Both means a UI caller creates the object in the UI thread (direct call to activation) and a thread pool caller creates the object on the same thread in the poolThink: "apartment-local activation"Agile and Both can be inter-mixed and are a very common combination. This should be the default for all non-UI objects.
www.buildwindows.com
Languages and agilityOS objects are as described previouslyWhen you write WinRT objects:JavaScript objects are all single-threadC# objects are all agile• Unless they derive from non-agile basis like UI
C++ objects can be either agile or non-agile• Default depends on type of object• Compiler warns if you do the wrong thing with non-agile object
www.buildwindows.com
Thread-bound objectsA very small number non-UI WinRT objects are thread-boundOnce they are created on a thread, they can only be used thereAll should give clear and simple error when misusedGenerally high context objects with expensive state or high responsivenessHandwriting recognitionImage codecsMediaNormally each instance of the object can only perform one taskSo you just need to decide on which thread you want that to happen
www.buildwindows.com
Global stateApps often need to store state that is shared between different viewsGlobal state should be stored as agile objects or agile referencesUse CoreApplication property storeEnsures easy access from any threadState lifetime ensured to match applicationWon’t cause another thread to stay aliveTest case where app is started by contract other than standard
www.buildwindows.com
Logical thread IDsWinRT calls carry with them a logical thread IDRetained for all calls in a chain across threads, processesDifferent ID for unrelated operationsLogically-related calls are allowed to reenterEnsures an object can call back to you to get additional information
www.buildwindows.com
ASTA – no reentrancy
ASTA thread
Dispatch call 1Outgoing call
Outgoing call completes
Call 1 completes
Dispatch call 2 Outgoing call
Outgoing call completes
Call 2 completes
Processing input and related calls
Processing input and all calls
Processing input and related calls
Processing input and all calls
Related callback
Call 2 waiting
Evaluate this session
Scan this QR code to evaluate this session and be automatically entered in a drawing to win a prize!
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.