Using threads in interactive systems: A case study

Using threads in interactive systems: A case study

by Carl Hauser, Christian Jacobi, Marvin Theimer, Brent Welch, Mark Weiser

My thoughts on the paper -

Important Points:
* Some threading paradigms introduced by the paper like monitoring are easy to be used, and thus are useful and convenient for the programmer.

* Some paradigms introduced are commonly used even today like sleepers, which are widely used even these days. Sleepers contribute to programming convenience by allowing background operations like garbage collecting to be separated from the primary tasks. Others like slack processes etc. are challenging.

* Serializers was an important paradigm introduced used commonly even today. I think serializers inspired the concept of thread pools, which is a set of fixed or variable number of threads created for the purpose of picking up events from a queue and performing the tasks concurrently. Thread pools should actually be considered as the new paradigm introduced called concurrency exploiters.
Thread pools are widely used for communications between 2 different server systems.

* The paper effectively describes common mistakes made in thread programming, like in usage if WAIT wherein predicate is not checked once the WAIT is over.

* It describes various new design issues that exist in threading paradigms, and tries to understand them and rectify them.

Deficiencies:
* Although it has been mentioned in the paper that task rejuvenation is controversial, I would like to add that the fact that it masks design flaws makes it an unfeasible approach. In typical systems, there are bound to be a lot of design flaws because of the complexity involved. And there is always a dearth of mechanisms/instrumentations to uncover these flaws. So any approach that masks these is not feasible at all.

* To me Deadlock avoider paradigm, seems to be a very simplistic way of trying to avoid deadlocks and there does not seem to be any reasoning as to how it would ensure deadlocks would be avoided. Though I am biased, because I am already aware of other mechanisms like graphing etc. that may not have existed at that point of time.

* I think the paper lacks in providing feasible solutions for usage of certain paradigms like slack processes. It seems the paper describes all the challeneges involved but fails to provide any solution on how the slack processes could be effectively used.

Conclusions :
I think this paper is a useful point of reference for programmers to determine the practical advantages of a particular thread paradigm, the common mistakes made in thread programming, flaws existing in the current thread paradigms, and also as a point of reference for researchers to do future research on paradigms that still require improvement or are not serving their purpose enough.

I think the most important lesson from the paper is that due to the complexity of threading systems, there are bound to be new design issues that arrive, and rather than building systems that try to masks these issues, the systems should be built to be able to accurately understand the root of these issues, understand them and rectify them.