Using Threads in Interactive Systems: A Case Study
Carl Hauser, Christian Jacobi, Marvin Theimer, Brent Welch and
Mark Weiser
Proceedings of the 14th ACM Symposium on Operating Systems Principles,
December 1993, pages 94-105
Notes updated by: Steve Zdancewic, 2 March 1999
Overview
This paper examines thread usage in the Cedar Programming
Environment and Global View for X Windows (GVX) to discover common
paradigms and typical mistakes.
- Statistical analysis (thread lifetimes, event spacing)
- Examine code
Mesa Thread/Syncronization Model
- Thread - Lightweight, pre-emptive, shared address
space, 7 priorities
- Monitor - Set of procedures sharing a mutex
(single thread in monitor at a time)
- Condition Variables - Explicit scheduling
- WAIT - thread blocks on a CV (not Hoare semantics)
- NOTIFY - wakens one thread blocked on a CV
- BROADCAST - wakens all threads blocked on a CV
Dynamic Thread Behavior
- Time slice 50 milliseconds
- Thread switch takes 50 microseconds on Sparcstation-2
- Switch rate: Cedar 130 - 270/sec, GVX 33 - 60/sec
- Execution invervals: Cedar 75% are 0-5 millisecs, GVX 50%-70% are
0-5 millisecs
- Total exectution time: Cedar 20%-50%, GVX 30%-80% time accumulated by threads
running for 45-50 millisecs
- Classified into three categories:
- Eternal - Repeatedly wait on CV, run briefly
- Worker - Performing some activity
- Transient - Spawned by long-lived thread, short lifetime
Paradigms of Thread Use:
- Defer Work - Reduce latency seen by client
(e.g. forking to print/send mail/create window) (30%)
- General Pumps - For pipeline structuring (14%)
- Slack Processes - Pumps that add latency to batch/compress output
- Sleepers - Wait for an event then execute
(e.g. run thread every M milliseconds) (19% - Cedar, 6% - GVX)
- One-Shots - Wait then execute once
- Deadlock Avoidance - Fork to avoid lock order
constraints (10% - Cedar)
- Task Rejuvenation - Forking a new copy of a thread that's in a bad
state
- Serializers - Queue + thread to serialize events from different sources
- Concurrency Exploiters - For multiple processors
(not studied)
- Encapsulated Fork - Wrap fork in useful package
to capture common usage
- DelayedFork and Periodical Fork - One-Shot/Sleeper
- MBQueue - Serializer for menu/button events
- Forked Callbacks - Callback flags for fork/no fork
Pitfalls and Issues
- Priorities are hard to use correctly.
- Programmers didn't use condition variables correctly
(WHILE vs. IF).
- Timeouts used to compensate for missing NOTIFY.
- What to do when fork fails?
- Spurious lock conflicts (again, priorities).
- Time-slice quantum