Pain Gain

1
Pain Gain?

• Paper 4 Why Threads Are a Bad Idea (for most
  purposes)
• Presented by Haoran Song

2
Background

• Today, We use two models to deal with concurrency
  problems.
• One is Thread, another is Events.
• Programmers hate thread programming just like
  that you can not concurrently play Tetris Game in
  two Person Mode.

3
Introduction to Threads

• Also called light weight processes
• Threads reduce overhead by sharing fundamental
  parts Memory, files, etc.
• Exploit Latency and contribute to Parallel
  Processing and Distributed Processing. Eg.
  Multi-thread Web Server
• It is widely used in OS, Scientific
  Applications, Distributed Systems, GUI and
  Animation.

4
Why thread is bad?

• We learned our first thread programming in 3rd
  year in undergrad. Most of students cant get an
  A in such a course.
• Everyone suffered the pain during the programming
  and debugging in thread. The thread programming
  in Tetris Game took 20 time.
• Hard to achieve good Performance.
• Eg. Simple locking causes low concurrency

5
Introduction to Events

• In the following picture the man acts as an event
  handler and the woman as a generator of time
  events.

6
Introduction to Events

• When the event occurs, the event generator sends
  a message to each of its event handlers saying
  that the event of interest occurred. The event
  handler can then carry out the task.

The man then carries out the task required at 9
o'clock, perhaps putting the chess set away and
leaving, perhaps proposing marriage.
7
Advantages of Events

• One execution stream, we do not need to worry
  about concurrency, deadlock. This means much
  easier to program.
• Mostly used in GUIs (press button, invoke menu
  entry, etc.)
• Handler implements behavior instead of creating a
  thread.
• In Distributed System and Mobile Agent System,
  handler processes incoming request, sends
  response.
• Event-driven I/O for I/O overlap

8
Disadvantages of Events

• Long-running handlers make application non
  responsive. Slow down the performance.
• Not suitable for CPU concurrency, especially
  scientific applications
• Event-driven I/O not always well supported.

9
Tradeoff

• If it is possible to use events to do the same
  job, use events instead of threads.
• If you think you are an expert in thread
  programming, do it! Otherwise, use events. Do not
  make your life too tough.
• Events is good for GUIs and Distributed System
  development.

10
Conclusion

• Threads is powerful, but sucks!
• Pains Gains
• But in certain circumstance, like database. No
  pain, no gain!

11

• Thanks!
• Questions

12

• What does it mean that standard libraries are
  not thread safe?
• ANS A piece of code is thread-safe if it
  functions correctly during simultaneous execution
  by multiple threads. In particular, it must
  satisfy the need for multiple threads to access
  the same shared data, and the need for a shared
  piece of data to be accessed by only one thread
  at any given time.

13

• With multi-core, hyper-threading, and
  multi-processor desktops, should we still avoid
  using threads?
• ANS This paper is not telling us to abandon
  threads. It is telling to carefully use threads.

14

• What kind of debugging tools are there available
  for debugging threaded applications anyways?

15

• In a typical GUI-based application, how many
  threads are actually used to handle the window
  display, keyboard strokes, and mouse clicks ?
• ANS In my Tetris Game, I did not use threads at
  all.

16

• I don't understand in the first slide named
  "Introduction" the phrase "Threads should be used
  only when true CPU concurrency is needed" to
  events. Does this mean that events provide a
  "non-true" concurrency?