fouts@orville.nas.nasa.gov (Marty Fouts) (01/05/88)
In article <2428@encore.UUCP> collins@encore.UUCP (Jeff Collins) writes: > > match between an application and the type machine to use. As an > attempt to further your point, let me give my perspective on the > various applications and machine solutions (from an admittedly biased > perspective). > He then goes on to define general-time sharing, and fine-grained parallelism by citing specific machines which he believes are good at each of the task, and concludes by declaring that course-grained parallelism is harder to define. As an alternative, I prefer the term "competitive multitasking" to describe "general-time sharing," although concurrency is a better word than multitasking. Starting from this point, my definitions are: Competitive Concurrency -> Multiple unrelated threads of control sharing physical resources. Time sharing systems are a good example. So are multiple partition batch systems. Competitive concurrency is used to obtain efficency through sharing of resources which would otherwise be idle. Can usually be achieved transparently in an i/o balanced multiprocessor. Cooperative Concurrency -> Multiple threads of control cooperating to solve the same problem. It is distinguished from Competitive Concurrency by a requirement to communicate and/or synchronize. Cooperative concurrency is used to minimize wall clock time (turn-around time) for the solution of a specific problem. Rather than jumping immediately to parallelism, I prefer to use three measures of interdependence to determine the effective degree of concurrency of a solution. Degree of Synchronization -> How often is it necessary for threads of control to wait on other threads achieving a certain state. Level of Communication -> How much data has to be transfered from one thread of control to another thread during the execution of the solution. Degree of Data Sharing -> How much data is unique to a given thread and how much is shared between one or more threads. (There are interrelationships here. For some architectures, data sharing may be achieved by communication, as may synchronization, for example.) I prefer these measures because they allow me to talk about concurrent algorithms in a way independed of particular architectures, and help me characterise what kinds of problems can be solved on what types of processors.
ccplumb@watmath.waterloo.edu (Colin Plumb) (01/06/88)
I'd like to support these definitions of competitive and cooperative concurrency. As an example, the Inmos Transputer is designed for cooperative concurrentcy, but is the absolute pits for competitive multitasking. This is why I'm pessimistic about the idea of making a general-purpose workstation out of Transputers. -- -Colin (ccplumb@watmath)