Armstrong Thesis Chapter 2

This introductory chapter accomplished two things: it did an excellent job of laying the foundation that will be expanded upon in later chapters and it whet my appetite. Since both of these things were accomplished I would consider that a resounding success.

At first while reading I was concerned as to why the author insisted that current Object Oriented languages would not be enough to complete the level of concurrency aimed at since it seemed that all that was occurring was the layering of additional interfaces and basic constraints over a current thread like architecture. It wasn't until the listings near the end of the chapter that stressed things like run-time code and library alteration that I began seeing why it was necessary to go beyond Java or C/++/#. It would have been nice to see the requirements listing for the OS, Language, Libraries, and other parts near the front of the chapter so that readers like me aren't spending the brain power asking "Why can't we just..." when the author has clearly already thought that through. There was one comment in the Operating System requirements section that I disagreed with greatly, namely that if the OS can create and destroy threads quickly then this is good enough to assume that this approach will scale well to systems with a large number of threads. I find this to be dangerous and short-sighted, to think that only at creation and destruction do threads add computational overhead to CPU work. Perhaps later sections will delve further into this. I can only hope.

The Next thing that really caught my eye was the introduction to security. The idea that a process or program needs the PID for access is an obvious one and the author correctly identifies that it will be the flow of this information that will expose security risks (assuming of course that choosing a PID is a sufficiently obfuscated process). When I got to those bullet points it raised a few questions about how they were actually going to tackle these issues, but unfortunately that sounds as though it will have to wait for later. Also somewhere in there is a concern about all messages passed are going to be atomic and how they exactly propose to pull this off.

Finally, it will be interesting to see if programming in such an environment is really going to be as easy and intuitive as the author claims it will be. Again though, this sounds like it will have to wait until later chapters are read.

All in all, it was an interesting start. I haven't found any horrible flaws yet which is always encouraging in a paper of this size, and the authors have done a good job of laying the foundation for what is to come.