By Topic

Concurrency with Erlang

Sign In

Cookies must be enabled to login.After enabling cookies , please use refresh or reload or ctrl+f5 on the browser for the login options.

Formats Non-Member Member
$31 $13
Learn how you can qualify for the best price for this item!
Become an IEEE Member or Subscribe to
IEEE Xplore for exclusive pricing!
close button

puzzle piece

IEEE membership options for an individual and IEEE Xplore subscriptions for an organization offer the most affordable access to essential journal articles, conference papers, standards, eBooks, and eLearning courses.

Learn more about:

IEEE membership

IEEE Xplore subscriptions

1 Author(s)
Vinoski, S. ; Verivue

Programmers writing multithreaded applications in languages like Java and C++ spend much of their time determining what state is shared among threads and how best to protect its integrity within the running application. Finding all the shared state isn't always easy. Assuming the programmer can even find it, he or she must then possess the skills, experience, and patience necessary to determine the best way to serialize access to it. Adding to the difficulty is the locking granularity used to protect shared state. If locking is too coarse-grained, the application tends toward single-threading, because only one thread at a time can obtain the lock that predictably surrounds a large portion of the code. Such applications make poor use of multicore CPUs and tend to be slow. If locking is too fine-grained, on the other hand, the chances for deadlock increase greatly as different threads are increasingly likely to obtain locks in different orders. Getting it right takes time: fine tuning what state needs protection, and at what granularity, sometimes requires months of development time. Idioms, patterns, and frameworks can help out partially, but they introduce restrictions and trade-offs of their own. Ultimately, all it takes is one developer overlooking one small piece of shared state to cause a large system to crash in production - usually at the worst possible time for the most important customer. One way to avoid the problems with shared state is to simply avoid it, but that's impractical in a language like C++ or Java. Doing so requires a combination of libraries or frameworks such as those based on actor models and message passing, as Guerraoui described. It also requires significant programmer discipline because the programming languages themselves can't do anything to help developers completely circumvent shared state. Rather than using the programming language as intended, the developer is forced to write in what's at best a one- off dialect or worse, a who- le new one-off language, using the special idioms and frameworks designed to help avoid sharing state among threads. A better way to avoid shared state is to switch to a programming language specifically designed to do exactly that. Erlang is one such language.

Published in:

Internet Computing, IEEE  (Volume:11 ,  Issue: 5 )