what every web and app developer should know about multithreading

3,313 views

Published on

talk at Barcamp LA 6

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

  • Be the first to like this

No Downloads
Views
Total views
3,313
On SlideShare
0
From Embeds
0
Number of Embeds
746
Actions
Shares
0
Downloads
97
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • By-nc-nd 2.0 Clemens Schwaighofer http://flickr.com/photos/gullevek/257135337/ Introduction to threading Time for questions at the end; if it’s really brief, interrupt me
  • what every web and app developer should know about multithreading

    1. 1. what every web and app developer should know about multithreading
    2. 2. why
    3. 3. why <ul><li>On the desktop, one core is rarely enough </li></ul><ul><li>On the web, sometimes we need parallel execution </li></ul><ul><li>Performance requires caching </li></ul><ul><li>Persistence of connectivity requires responsiveness </li></ul><ul><li>Disk and network I/O is indispensible and v ery slow </li></ul>
    4. 4. threads <ul><li>A way to execute two things at once </li></ul>
    5. 5. threads <ul><li>A way to execute two things almost at once </li></ul><ul><li>Lightweight </li></ul><ul><li>Independent execution </li></ul><ul><li>Almost like a separate process </li></ul>
    6. 6. thread process versus
    7. 7. thread <ul><li>A process is isolated in memory </li></ul><ul><li>When it dies, its memory is released </li></ul><ul><li>When it dies, its threads die too </li></ul><ul><li>Somewhat difficult to talk to other processes </li></ul>versus
    8. 8. <ul><li>All threads in a process share memory </li></ul><ul><li>Can be started and stopped as needed </li></ul><ul><li>On some platforms, cheaper to launch than a process </li></ul><ul><li>Can be native (kernel-based) or user-mode </li></ul>process versus
    9. 9. threads
    10. 10. threads <ul><li>Less predictable execution </li></ul><ul><li>Must control for re-entrancy of code </li></ul><ul><li>Must be aware of shared data </li></ul><ul><li>More difficult than it seems </li></ul>
    11. 11. synchronization <ul><li>We must retain predictability in our programs </li></ul><ul><li>Two threads fighting for the same variable </li></ul>Thread A my_local_x = x set x = my_local_x + 1 Thread B my_local_x = x set x = my_local_x + 2
    12. 12. synchronization <ul><li>We must retain predictability in our programs </li></ul><ul><li>Two threads fighting for the same variable </li></ul>Thread A my_local_x = x set x = my_local_x + 1 Thread B my_local_x = x set x = my_local_x + 2 <ul><li>If we started out with x = 2, we end up with x = 5 </li></ul>
    13. 13. synchronization <ul><li>We must retain predictability in our programs </li></ul><ul><li>Two threads fighting for the same variable </li></ul>Thread A my_local_x = x set x = my_local_x + 1 Thread B my_local_x = x set x = my_local_x + 2 <ul><li>If we started out with x = 2, we end up with x = 5 </li></ul>
    14. 14. synchronization <ul><li>We must retain predictability in our programs </li></ul><ul><li>Two threads fighting for the same variable </li></ul>Thread A my_local_x = x set x = my_local_x + 1 Thread B my_local_x = x set x = my_local_x + 2 <ul><li>If we started out with x = 2, we end up with x = 4 </li></ul>
    15. 15. synchronization <ul><li>First rule of synchronization: avoid needing it </li></ul><ul><li>Thread-local storage </li></ul><ul><li>Function scope variables </li></ul><ul><li>No side effects </li></ul><ul><li>Functional languages </li></ul>list.sort()
    16. 16. synchronization <ul><li>First rule of synchronization: avoid needing it </li></ul><ul><li>Thread-local storage </li></ul><ul><li>Function scope variables </li></ul><ul><li>No side effects </li></ul><ul><li>Functional languages </li></ul>list.sort() newlist = list.sort()
    17. 17. synchronization <ul><li>Second rule of synchronization: join threads </li></ul><ul><li>Use a worker thread </li></ul><ul><li>Join – wait for it to finish, then read its results </li></ul>
    18. 18. synchronization Thread A Thread B Main Thread Start A Start B Join A and B Read data
    19. 19. synchronization <ul><li>Third rule of synchronization: go critical </li></ul><ul><li>Declare a critical section </li></ul><ul><li>You are alone within your application… </li></ul><ul><li>… until you end the critical section </li></ul><ul><li>Application-wide setting </li></ul><ul><li>Hard to use when you have a bunch of threads </li></ul>
    20. 20. synchronization <ul><li>Third rule of synchronization: mutual exclusion </li></ul>
    21. 21. synchronization <ul><li>Third rule of synchronization: mut ual ex clusion </li></ul>
    22. 22. synchronization <ul><li>Third rule of synchronization: mutex </li></ul><ul><li>Allows you to “lock” and “unlock” resources </li></ul><ul><li>Like an object for a mini-critical section </li></ul><ul><li>Thread A </li></ul><ul><li>lock M </li></ul><ul><ul><li>my_local_x = x </li></ul></ul><ul><ul><li>set x = my_local_x + 1 </li></ul></ul><ul><li>unlock M </li></ul><ul><li>Thread B </li></ul><ul><li>lock M </li></ul><ul><ul><li>my_local_x = x </li></ul></ul><ul><ul><li>set x = my_local_x + 1 </li></ul></ul><ul><li>unlock M </li></ul>
    23. 23. synchronization <ul><li>Third rule of synchronization: use a semaphore </li></ul><ul><li>Like a mutex, but lets more than one thread through </li></ul><ul><li>Mutex with a counter </li></ul><ul><li>Checks availability, then “acquires” one count </li></ul><ul><li>When done, “releases” one count, unblocking others </li></ul>
    24. 24. synchronization <ul><li>Synchronization is about blocking </li></ul><ul><li>Allows you to control access to code and data </li></ul><ul><li>Protects areas of code that shouldn’t be left to chance </li></ul>
    25. 25. examples <ul><li>Worker threads </li></ul><ul><li>Thread pools </li></ul><ul><li>Producer / Consumer </li></ul><ul><li>Cache </li></ul><ul><li>Will use .NET for examples </li></ul>
    26. 26. example
    27. 27. example
    28. 28. example
    29. 29. example
    30. 30. bad threading
    31. 31. bad threading <ul><li>It is simple when simple, and fiendish when complex </li></ul><ul><li>Watch out for race conditions: lock often to prevent </li></ul><ul><li>Watch for deadlocks: don’t lock too much </li></ul><ul><li>Watch for incomplete locks: lock carefully </li></ul>
    32. 32. bad threading <ul><li>Lock for the smallest amount of time </li></ul><ul><li>If possible, lock for consistency… </li></ul><ul><li>… then copy the data and use it locally </li></ul><ul><li>Instead of blocking on locks, wait with a timeout </li></ul><ul><li>Use lots of debug logging if you’re in trouble </li></ul>
    33. 33. photo credits CC BY-NC-ND 2.0 – Clemens Schwaighofer – http://flickr.com/photos/gullevek/257135337/ CC BY-NC-SA 2.0 – Robert Parviainen – http://flickr.com/photos/rtv/2574427997/ CC BY-NC-ND 2.0 – Sudhir Srinivasa – http://flickr.com/photos/sudhirs/111760673/ CC BY-NC-SA 2.0 – Rick Harrison – http://flickr.com/photos/sovietuk/2657691123/ CC BY-NC-ND 2.0 – Joe Chiapputo – http://flickr.com/photos/cocoabeachjoe/1924133031/ CC BY-ND 2.0 – Craig Allen – http://flickr.com/photos/anabadili/2759448841/

    ×