A World Of Concurrency
By Wajdi Al-Judaibi
Islam Online, Washington DC
The days of writing simple programs are over!
Computers are now part of our daily activities, they have become an
essential tool for businesses, education and scientific research.
The extensive spread of software usage has resulted in more and more
complex software systems that require a great deal of capabilities
and expertise to build and maintain. Although the artistic nature of
writing software might never be completely eliminated, writing
software has emerged as an engineering discipline rather than a
craft. The term, which has been agreed upon by the software
community, is preferably phrased as software engineering. A
discipline that draws the proper framework for writing correct,
reliable, robust and maintainable software systems.
As hardware capabilities advance, software has
become increasingly richer in features and thus harder to develop and
understand by developers. Yet, the complexity associated with
writing software must be hidden from the end user. This has been an
ongoing trend between software complexity and user-friendliness. To
satisfy both ends of the equation, software systems must be modeled
to give an exact representation of the real world problems that they
solve. Hence, concurrency becomes an issue since many real world
problems are inherently concurrent. The world around us is highly
concurrent, and so should software systems be if they are to solve
any one of them. Furthermore, with the current trend towards
distributed computing (i.e. the Internet), more software systems are
being developed with support for concurrency to accommodate the fact
that computers nowadays control a wide range of devices and
machines.
A
concurrent system typically has many parts (processes) running at
the same time. The opposite of concurrency is where the execution of
a program flows in a pre-determined path from start till finish,
better known as sequentiality. The degree of concurrency in a system
is determined based on a granularity factor that constitutes a scale
of concurrency. The lower end of the scale is represented by fine
grained concurrency, while its upper end represents coarse grained
concurrency. A fine grained concurrent program may be one performing
mathematical calculations and executing several of its operations in
parallel. A concurrent program with a coarser granularity, on the
other hand, would be a program which has two or more processes
running in parallel, each executing several distinct operations and
each of which has its own life thread throughout the execution time
of the program. At the upper end of the scale, one would find
systems with several networks of computers run and communicate in
parallel. In general, concurrency as a technical term includes the
terms parallel execution, parallel programming, parallel processing,
distributed computing, etc.
One may ask, what are the merits and demerits of
concurrency? And why it is needed? The answer is, partially, a
simple one; mainly due to the fact that developing concurrent
solutions is a harder task than reasoning about it. Concurrency
provides a higher level of problem understanding, more flexibility
and supposedly higher performance than that found in sequential
software systems.
Moreover, some software systems can’t be
represented by sequential ones. For instance, an air conditioning
system controls the temperature of a building by monitoring a series
of thermostats throughout the building during its normal operation.
Another example would be an air traffic controller who must deal
with hundreds of airplanes simultaneously. In such environments,
concurrency is not a convenience or a better tool for understanding.
Rather, it is a must for a correct solution. A downfall of
concurrency is that it adds more complexity during several phases of
software development; and in many cases, concurrent software
requires a capable hardware platform in order to reach viable levels
of performance.
The requirements phase includes the analysis of
the software problem and drafting it in a either a formal or a
pictorial representation. The requirements phase usually concludes
with a complete specification of the desired external and the
initial internal behaviors of the system. In most cases, Object
Oriented Analysis (OOA) is the method of choice used for
understanding and modeling requirements; also it is well situated
for modeling
concurrency. The object model, which is the first part of
OOA, gives a highly concurrent representation of the software
environment. Each class in the object model represents a real life
entity that has its own life thread.
To minimize the complexity associated with
building concurrent software systems, analysts and designers have
resorted to the use of formal methods to eliminate ambiguities and
reach a precise description of the software. Formal methods are
specification and design methods that are mathematically based and
thus maintain a much needed level of precision and rigor for
concurrent systems. Among the many formal methods available, three
are highly distinguishable: Calculus of Communicating Systems (CCS),
Communicating Sequential Processes (CSP), and Language of Temporal
Orderings (LOTOS), all of which are formal specification methods
that are concerned with modeling process communication and ordering
of events. LOTOS, however, which is based on the roots of CCS and
CSP, provides an extended mechanism that allows for abstract data
types. The language has become an ISO standard in 1989 and is widely
used in the industrial and research communities.
Regardless of the difficulties that concurrency
may present, it has received wide attention in recent years.
Concurrent software systems have proven to be essential for a wide
range of applications such as real-time systems, embedded software
systems, safety critical systems, and distributed Systems. Mapping
the parallel behavior found in the real world onto software models
increases problem-space understandability and paves the road for
reasonable future maintenance effort.
|
