Threading model in Windows Store apps

Mirco Vanini

Microsoft® MVP Windows Embedded

Why threads?

Windows threading model

Objects and threading – Marshaling

Agile objects

Thread pool threads

Using the thread pool in Windows Runtime apps

Agenda

Service connected world

Responsive apps

Touch-based experience

Many cores

Why threads?

Kernel threads

Separate processes

Brokers

Async operations

How Windows parallelizes for you

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

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

Windows threading modelApp

Windows UI

Object

Main UI Thread

Windows

Object

Threadpool

App Code App Code App Code

Windows

Object

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

Brokered Objects

RuntimeBroker.exe

Windows Runtime Object

IInspectable

IUnknown

App

Pro

jecti

on

Pro

xy

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

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

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

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

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

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

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

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

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

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

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

Submitting a work

item to the thread

pool dem

o

Submit a work item

using a timer

dem

o

Create a periodic work

item

dem

o

Respond to named

events and

semaphores dem

o

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

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

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

Q&A

Contact

feedback

10

Bloghttp://mircovanini.blogspot.com

Email info@proxsoft.it

Web www.proxsoft.it

Twitter @MircoVanini