This entry is one of many entries that I’m writing for a journal assignment in my Systems Integration course through Carnegie Mellon. The idea is to answer the question “Why is this particular concept important?” I decided to bring some Web 2.0 to this assignment and leverage my blog. Besides … journaling is for filesystems.
Being new at Boeing and fresh out of college, I havent had much professional experience integrating a huge collection of enterprise systems. It goes without saying, comparatively to my classmates who are actively working on a systems integration project or have so in the past, that my experience is limited. In fact, it is purely academic at this point. So when I viewed the lecture on concurrency, it immediately reminded me of back in the day in my Operating Systems class and the Dinning Philosophers Problem — a classic problem that, I’m sure, many classes dealing with parallel processing use as a teaching tool. The Dining Philosophers Problem, as a quick primer, is a multi-process problem in which computers (The philosophers) are competing for resources (forks to eat with). It is commonly used to teach the concept of deadlock.
Deadlock, as illustrated in the diagram above, is a condition in which two processes are waiting for each other to release a resource in a cyclical manner. And Trust me. Deadlock was something I was all too familiar with when tasked with implementing Dinning Philosophers as an assignment.
In the context of whole systems and systems integration, it is quite easy to see the similarities in concepts. Rather than processes, objects are abstracted to whole systems. Semaphores and mutexes become locks. Instead of processes sleeping, systems wait. Systems compete for resources such as databases, files, and hardware instead of shared space in memory. Thankfully having had studied parallel processing in my operating systems class as an undergrad made studying concurrency in the context of system integration much easier. The fundamental problems and balances of computing tend to follow you where ever you go, whether you learn about the low levels of the cpu to integrating whole systems — and in academia, everything seems to be abstracted to links and nodes anyways.
It also goes without saying that the same problems found when processes deadlock are found when integrated systems become deadlocked. Just as if you don’t manage your threads and shared resources correctly in a program, an integrated system can reach a state where no work can be done. Also you certainly do not want systems clobbering a shared resource such as a database table that another system is currently reading from. A system’s trust is questionable when the system integration and concurrency is not particularly designed well. Concurrency is especially relevant for me considering I work at Boeing, a company that makes airplanes. I’m almost certain that an integrated system deadlocking mid-flight might not be a good thing necessarily.
Note to Dr. Butler: Feel free to leave my feedback and grade via the commenting system below. Good or bad, I don’t mind.
When reading from a database, if the system supports it, multiple concurrent reads are a-ok. Why? Nobody is going to modify anything, therefore there shouldn’t be any reason to worry about resource synchronization problems (I say shouldn’t because some SELECT statements may require a lock on the table(s) involved, or the database as a whole). However, a lock, whether it be a stored “mutex” key in another table or a database-system-supported table(s) lock is necessary for every write. For every write, lock, then write, and if the transaction completed successfully, commit and unlock (otherwise rollback). While the lock is in, then no other system has access. But then this too creates a problem as it slows things down. The solution: DB system-side cached queue or a distributed DB system. A good example of this is Twitter - imagine getting over 5000 INSERT requests and having to handle over 20000 SELECT requests at the same time. It would be a nightmare and things would slow to a crawl. Fortunately, they use a combination of distributed DBs and caching to handle the load (hence stale results in some cases), but the system overall moves smoothly. I’ve been considering needing to implement a concurrent DB system for a personal project that I’m planning, but I still need to flesh out more details (heck, I thought about it just a couple days ago and have been trying to work it out in my head).
Sean
October 3rd, 2008
This is the worst work I have ever seen as a professor in my long and fruitful tenure at CMU.
haha. had you going, though aj. –disgracer of many families
Dr. Butler (Brian)
October 3rd, 2008
Mike
October 4th, 2008
Shawn A. Butler, Ph.D.
October 15th, 2008