Questions Submitted for Paper# 4 |
| 1. In slide 7, the figure on the left seems to show a design flow rather
than a thread problem. I think a thread shouldn't go to sleep after
acquiring a lock. Am I wrong? 2. Can event driven programming be extended to interprocess events too? That is can say a process spawn another process and then wait on a handler? If so, is there a definite way to model thread implemented programs as event driven programs? |
| 3. How does one prevent an event handler from hogging the CPU and
never releasing it 4. Even normal desktop computing environment requires a notion of concurrency, how will a purely event based solution work in this case |
| 5. I think for event-driven programming, programmers should define a
set of events possible occur or have to handle with. Then if there are
some events not included in your predefined events, what will happen ? 6. Is command line a kind of event here ? If yes, then is a key press or the whole command considered to be an event ? |
| 7. What is the cost of entering and leaving an event handler? 8. How does that compare to a context switch (on a kernel-threads system, as well as a user-threads system)? 9. Slide 7: Why do callbacks *necessarily* not work with locks? |
| 10. To what extent are the problems with threaded programming
described here unique to concurrency in general, as opposed to being
unique to threading specifically? 11. Ousterhout cites a single execution stream as being a benefit to event driven programming, but in a sense repackaging an execution thread into a collection of events and handlers could make code difficult to reason about. What are the trade-offs here? 12. Can we typify the overhead of marshalling and unmarshalling data through a message passing system? |
|
13. What are the advantages of
events compared to threads?
14. What are the disadvantages of
events compared to threads? |
| 15. Is it true that in scientific applications one thread per CPU
will solve problems more quickly? 16. The paper compares Event and Threads and lists lots of advantages of Events. Does this mean that Event can replace Thread at all? |
| 17: It seems that there is a general feeling, especially when
one looks around on Google, that threads are to be avoided, as the paper
indicates, because it's difficult. Why then is it that there are
so many threaded applications floating around in comparison to
Event-based ones? Are programmers masochistic by nature or
something? 18: As an aside, what kind of debugging tools are there available for debugging threaded applications anyways? |
| 19. How could you wait at the same time for multiple IO events to
happen without decreasing performance ? 20. In a typical GUI-based application, how many threads are actually used to handle the window display, keyboard strokes, and mouse clicks ? |
| 21. Doesn’t concurrency help performance? The slide 8 and 12 insists
that using threads does not help to achieve good performance and events
are faster than threads. Is there another paper to show the comparison
results? 22. what is a better combination between “user threads + kernel threads” and “event-driven handlers + kernel threads”? If the latter is better than the former, the latter could be a substitute for the scheduler activation proposed in the paper #3? |
| 23. Are events really useful for anything other than I/O? 24. I guess you hope that event handlers are fast but why if you have a queue of events waiting to be processed, and when you factor in event priority, are events really that much better than threads? |
|
25. If the amount of time needed to process an event
varies greatly, how would an event handler decide when to create an
external thread to process the event? |
| 27. On slide 8 (page 4) it is mentioned that that standard libraries
are not thread safe. My understanding is that "thread safe" means
multiple threads can call the same library concurrently without having
problems (shared data is managed correctly). Is this right? If the
answer is yes, do we have any thread safe standard libraries today?
28. What is the problem with having callbacks and locks together? Does it happen in all the cases? 29. What is the "event loop" overhead? |
| 30. How do threads break abstractions?
31. What does IO overlap means? |
| 32. Ousterhout's main point seems to be use an appropriate
programming paradigm for the task at hand. For him, GUI interaction is
best suited using an event based mechanism, rather than threads. This
seems to be based on the lack of deadlock/synchronization issues
associated with event programming. Are you aware of thread-based
programming paradigms that provide the benefits of concurrency while
avoiding the pitfalls of synchronization?
33. I disagree with the statement (slide 8) that threads are hard to port. POSIX threads (pthreads) are available on most OSes (Mac, Windows, Linux), and threading in Java is transparent across all implementations. Does portability change any of the arguments that Ousterout puts forth? |
| 34. The paper says that you can't maintain local state across
invocations of an event handler, but isn't it possible if you implement
event handlers as objects?
35. Why aren't thread-safe (versions of) standard libraries more common? It would make threaded code a lot less painful to write. Surely there's a market for them. |
|
36. The presentation made some claims such as events are faster than threads on single CPU, and threads
are not portable without giving any justification. Can you come up with any examples/data that proves/disprove
these claims? 37. With multi-core, hyper-threading, and multi-processor desktops, should we still avoid using threads? Given that threads and events both have their short comings, did the recent development in hardware tip the scale towards using threads? |
| 38. 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?
Am I wrong in thinking that events do not provide concurrency? 39. How would you comment on the circular dependencies among locks stated on the slide named "Why Threads Are Hard" in view of the technique given in paper #1 where is it said that locking on semaphores is always done in the same order to avoid deadlocks? 40. In slide "Why Threads Are Hard, con'd" it is stated that callback's don't work with locks. Can callbacks be a part of a system that works with threads (I don't mean user created threads, but those created by the operating system)? 41. What does it mean that standard libraries are not thread safe? (This is on the slide after the one in question 4.) Standard libraries are there to be read and not to be written into, so where does the safety issue come in? 42. We have seen in the previous class how pipelining (in hardware) works with threads. How would pipelining work in an event-based operating system? 43. Would an event based system support daemon processes? 44. The author mentions forking off sub-processes for long-running things in slide named "Problems With Events". Isn't this threading in a way? |
| 45. In the very first version of Java, there was no way to do
networking I/O except by using blocking calls, and thus threads. Was the
presentation a political maneuver to bring this issue to the forefront? 46. Was threads programming particularly widespread at the time the presentation was made? 47. What else is the presenter famous for (besides this infamous presentation)? |
| 48. One of the advantages of threaded code is that the individual
threads do follow a sequential path of execution that can be fairly
easily understood by reading the program text. In comparison, it can be
very difficult to understand the flow of control in programs that use
callbacks because it is impossible to simply trace a path. In large
projects, then, do callbacks really improve the productivity of
programmers relative to large projects that use threads?
49. The author states that threads should be used over events when more than one physical CPU is actually present ("true CPU concurrency"). Given that this is likely to become the general case in the very near future, how relevant are the points made in this talk today? |
Discussions |
| Today, I presented the paper# 4,"Why threads are
a bad idea (for most purposes)", by J. Ousterhout. Actually,
paper#4 is presentation slides rather than research paper. We discussed
problems and issues about when and where to use events other than
threads, comparing with advantages and disadvantages in both. There is a
lot of tradeoffs to consider. The usage of threads and events depends on
special circumstances, system requirements and user requirements. We
concluded that this paper is not to forbid us to use threads; Instead,
it recommends us to use threads carefully and take events as priority if
the threads are not necessary. However, due to the limited presentation time left for me, I did not finish my last 2 page slides.
|
| Presentation Slides can be downloaded here |