Concurrent Programming Article Index for
Concurrent
Website Links For
Concurrent
 

Information About

Concurrent Programming





CONCURRENT INTERACTION AND COMMUNICATION

In some concurrent computing systems communication between the concurrent components is hidden from the programmer (e.g., by using futures), while in others it must be handled explicitly. Explicit communication can be divided into two classes:

; and C# ). This style of concurrent programming usually requires the application of some form of locking (e.g., Mutexes , Semaphores , or Monitors ) to coordinate between threads.

; and Occam ). The exchange of messages may be carried out asynchronously (sometimes referred to as "send and pray", although it is standard practice to resend messages that are not acknowledged as received), or may use a rendezvous style in which the sender blocks until the message is received. Message-passing concurrency tends to be far easier to reason about than shared-memory concurrency, and is typically considered a more robust form of concurrent programming. A wide variety of mathematical theories for understanding and analyzing message-passing systems are available, including the Actor Model , and various Process Calculi .


COORDINATING ACCESS TO RESOURCES

One of the major issues in concurrent computing is preventing concurrent processes from interfering with each other. For example, consider the following algorithm for making withdrawals from a checking account represented by the shared resource balance:

1 bool withdraw(int withdrawal) {
2 if( balance > withdrawal ) {
3 balance = balance - withdrawal;
4 return true;
5 } else return false;
6 }

Suppose balance=500, and two concurrent processes make the calls withdraw(300) and withdraw(350). If line 2 in both operations executes before line 3 both operations will find that balance > withdrawal evaluates to true, and execution will proceed to subtracting the withdrawal amount. However, since both processes perform their withdrawals, the total amount withdrawn will end up being more than the original balance. These sorts of problems with shared resources require the use of Concurrency Control , or Non-blocking Algorithm s.

Because concurrent systems rely on the use of shared resources (including communications mediums), concurrent computing in general requires the use of some form of Arbiter somewhere in the implementation to mediate access to these resources. This introduces the possibility that problems with Unbounded Nondeterministic decisions can arise, although careful design of the arbiters can reduce the probability of these situations arising in practice to near zero.


CONCURRENT PROGRAMMING LANGUAGES

Concurrent programming languages are Programming Languages that use language constructs for Concurrency . These constructs may involve Multi-threading , support for Distributed Computing , Message Passing , Shared Resources (including Shared Memory ) or Futures (known also as ''promises'').

Today, the most commonly used programming languages that have specific constructs for concurrency are Java and C# . Both of these languages fundamentally use a shared-memory concurrency model, with locking provided by Monitors (although message-passing models can and have been implemented on top of the underlying shared-memory model). Of the languages that use a message-passing concurrency model, Erlang is probably the most widely used in industry at present.

Many concurrent programming languages have been developed more as research languages (e.g. Pict ) than as languages for production use. However, languages such as Erlang, Limbo, and occam have seen industrial use at various times in the last 20 years. Languages in which concurrency plays an important role include:


Many other languages provide support for concurrency in the form of libraries (on level roughly comparable with the above list).


MODELS OF CONCURRENCY

There are several models of concurrent computing, which can be used to understand and analyze concurrent systems. These models include:



SEE ALSO