Threading model in windows store apps

1,338 views
1,100 views

Published on

A overview about the Threading model in windows store apps

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,338
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Threading model in windows store apps

  1. 1. Threading model in Windows Store apps Mirco Vanini Microsoft® MVP Windows Embedded
  2. 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. 3.  Service connected world  Responsive apps  Touch-based experience  Many cores Why threads?
  4. 4.  Kernel threads  Separate processes  Brokers  Async operations How Windows parallelizes for you
  5. 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. 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. 7. Windows threading model App Windows UI Object Main UI Thread Windows Object Threadpool App Code App Code App Code Windows Object
  8. 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. 9. Brokered Objects RuntimeBroker.exe Windows Runtime Object IInspectable IUnknown App Projection Proxy
  10. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 21. Submitting a work item to the thread pool demo
  22. 22. Submit a work item using a timer demo
  23. 23. Create a periodic work item demo
  24. 24. Respond to named events and semaphores demo
  25. 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. 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. 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. 28. Q&A
  29. 29. Contact feedback 10 Blog http://mircovanini.blogspot.com Email info@proxsoft.it Web www.proxsoft.it Twitter@MircoVanini

×