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