Concurrent programming with SCOOP

Overview

SCOOP is Simple Concurrent Object-Oriented Programming. SCOOP allows developers to create object-oriented software systems which will take advantage of multiple, concurrently active execution engines while providing strong guarantees that allow programmers to reason like in sequential programs. Read further to get a better idea of what all this means, but for now, the primary message should be: SCOOP is concurrent software development made easy. The basic SCOOP ideas were first published as early as 1993. Since that time, considerable research and development has refined the SCOOP into the model that is implemented in EiffelStudio today.

Note: As you begin to use SCOOP you should make sure that you correctly set up your project. Information on how to do this can be found at Getting Started with SCOOP. Also consider compiling and working with some of the many SCOOP examples.

Concurrency

Concurrency in computation is a situation in which we can expect that a running computer system will have multiple computations executing simultaneously in a controlled fashion to achieve the goals of the system. The simultaneous executions can be handled by widely diverse computational engines: separate networked computer systems, separate processors in the same CPU, separate processor cores on a single chip, separate processor threads within a process, separate processes on the same CPU, etc...

Concurrent systems would not cause much trouble if the portions of the systems on different processors, processes, or threads were completely independent, that is, they shared no resources. But that would be a rare case indeed. In a concurrent system, simultaneously executing software elements can and do share resources and communicate with each other. This is where the problems can arise; problems in the form of various synchronization issues such as race conditions, atomicity violations, and deadlocks. The issues boil down to two essential problems in allowing access to shared resources:

1. Provide Safety: Make certain that nothing bad ever happens, like two threads that access the same memory in no defined order, or an invalid interleaving of operations that causes the program to crash.
2. Ensure Progress: Make certain that every participating thread eventually gets the opportunity to execute. Possible problems in this category are deadlocks, starvation (a thread keeps a lock forever, causing another one to wait), fairness etc...

Concurrency control is a rich research area in computer science. Consequently, many schemes have been designed to control concurrent computation.

SCOOP is such a model for concurrent computation which differs in some areas from other research efforts.

First, it is a goal of SCOOP to abstract the notion of concurrency to a level above the tools and techniques that are currently available. What this means is that if you were writing a system with multiple process threads, you could do that without SCOOP, using the tools that are currently used in multi-threaded programming, like semaphores and mutexes. Or you could write it in SCOOP using only the SCOOP mechanisms. Likewise with SCOOP, a system intended to run on multiple processors or multiple processor cores also could be written using only those same SCOOP mechanisms that you used for the multi-threaded system.

Second, the SCOOP model depends primarily upon Design by Contract with slightly changed contract semantics, and a single new keyword separate added to the Eiffel programming language. As you will see, the semantics of preconditions differ with concurrent execution versus sequential. Also, there are other underlying concepts and rules that need to be understood, but the point is that concurrent Eiffel using SCOOP will look a lot like sequential Eiffel.

Third, SCOOP uses the common act of argument passing to identify the necessity for guaranteeing exclusive access.

We will examine the details of how all this fits together and what it means to you as you begin to build concurrent software in Eiffel using SCOOP.