The set of useful programs resembles the Mandelbrot set
(shown in Figure )
in that it does
not have a clear-cut smooth boundary -- if it did, the halting problem
would be solvable.
But we need APIs that real people can use, not ones that require a
Ph.D. dissertation be completed for each and every potential use.
So, we ``shave the Mandelbrot set'',15.1restricting the use of the
API to an easily described subset of the full set of potential uses.
Such shaving may seem counterproductive. After all, if an algorithm works, why shouldn't it be used?
To see why at least some shaving is absolutely necessary, consider a locking design that avoids deadlock, but in perhaps the worst possible way. This design uses a circular doubly linked list, which contains one element for each thread in the system along with a header element. When a new thread is spawned, the parent thread must insert a new element into this list, which requires some sort of synchronization.
One way to protect the list is to use a global lock. However, this might be a bottleneck if threads were being created and deleted frequently.15.2Another approach would be to use a hash table and to lock the individual hash buckets, but this can perform poorly when scanning the list in order.
A third approach is to lock the individual list elements, and to require the locks for both the predecessor and successor to be held during the insertion. Since both locks must be acquired, we need to decide which order to acquire them in. Two conventional approaches would be to acquire the locks in address order, or to acquire them in the order that they appear in the list, so that the header is always acquired first when it is one of the two elements being locked. However, both of these methods require special checks and branches.
The to-be-shaven solution is to unconditionally acquire the locks in list order. But what about deadlock?
Deadlock cannot occur.
To see this, number the elements in the list starting with zero for the
header up to for the last element in the list (the one preceding the
header, given that the list is circular).
Similarly, number the threads from zero to
.
If each thread attempts to lock some consecutive pair of elements,
at least one of the threads is guaranteed to be able to acquire both
locks.
Why?
Because there are not enough threads to reach all the way around the list.
Suppose thread 0 acquires element 0's lock.
To be blocked, some other thread must have already acquired element 1's
lock, so let us assume that thread 1 has done so.
Similarly, for thread 1 to be blocked, some other thread must have acquired
element 2's lock, and so on, up through thread , who acquires
element
's lock.
For thread
to be blocked, some other thread must have acquired
element
's lock.
But there are no more threads, and so thread
cannot be blocked.
Therefore, deadlock cannot occur.
So why should we prohibit use of this delightful little algorithm?
The fact is that if you really want to use it, we cannot stop you. We can, however, recommend against such code being included in any project that we care about.
But, before you use this algorithm, please think through the following Quick Quiz.
Quick Quiz 15.1: Can a similar algorithm be used when deleting elements? End Quick Quiz
The fact is that this algorithm is extremely specialized (it only works on certain sized lists), and also quite fragile. Any bug that accidentally failed to add a node to the list could result in deadlock. In fact, simply adding the node a bit too late could result in deadlock.
In addition, the other algorithms described above are ``good and sufficient''. For example, simply acquiring the locks in address order is fairly simple and quick, while allowing the use of lists of any size. Just be careful of the special cases presented by empty lists and lists containing only one element!
Quick Quiz 15.2: Yetch! What ever possessed someone to come up with an algorithm that deserves to be shaved as much as this one does??? End Quick Quiz
In summary, we do not use algorithms simply because they happen to work. We instead restrict ourselves to algorithms that are useful enough to make it worthwhile learning about them. The more difficult and complex the algorithm, the more generally useful it must be in order for the pain of learning it and fixing its bugs to be worthwhile.
Quick Quiz 15.3: Give an exception to this rule. End Quick Quiz
Exceptions aside, we must continue to shave the software ``Mandelbrot
set'' so that our programs remain maintainable, as shown in
Figure .
Paul E. McKenney 2011-12-16