Chapters: History, sequential programming, concurrent programming, error handling, advanced topics
They say it takes four days to complete the course. If you know a little Prolog and a little LISP it takes you rather a few hours.
The Little Book of Semaphores is a free (in both senses of the word) textbook that introduces the principles of synchronization for concurrent programming.
In most computer science curricula, synchronization is a module in an Operating Systems class. OS textbooks present a standard set of problems with a standard set of solutions, but most students don't get a good understanding of the material or the ability to solve similar problems.
The approach of this book is to identify patterns that are useful for a variety of synchronization problems and then show how they can be assembled into solutions. After each problem, the book offers a hint before showing a solution, giving students a better chance of discovering solutions on their own.
The book covers the classical problems, including "Readers-writers", "Producer-consumer", and "Dining Philosophers". In addition, it collects a number of not-so-classical problems, some written by the author and some by other teachers and textbook writers. Readers are invited to create and submit new problems.
The process of writing large parallel programs is complicated by the need to specify both the parallel behaviour of the program and the algorithm that is to be used to compute its result.
concurrent paradigm, namely functional programming extended with threads and ports, which I call multi-agent dataflow programming. * The declarative concurrent subset (no ports) has no race conditions and can be programmed like a functional language. The basic concept is dataflow synchronization of single-assignment variables. A useful data structure is the stream, a list with dataflow tail used as a communication channel. * Nondeterminism can be added exactly where needed and minimally, by using ports - a named stream to which any thread can send. * All functional building blocks are concurrency patterns. Map, fold, filter, etc., are all useful for building concurrent programs. * Concurrent systems can be configured in any order and concurrently with actual use of the system. * Designing concurrent programs is any declarative part of the program can be put in own thread, loosening the coupling between system's parts * The paradigm is easily extended
JoCaml is Objective Caml plus (&) the join calculus, that is, OCaml extended for concurrent and distributed programming. The new JoCaml is a re-implementation of the now unmaintained JoCaml by Fabrice Le Fessant. With respect to this previous implementation, main changes are: * Numerous syntax changes, we believe the new syntax to be cleaner. * Disparition of mobility features, sacrified for the sake of OCaml compatibility. * Much better compatibility with Objective Caml. o Source compatibility is about 99%, there are three new keywords (def, reply and spawn) ; or and & should definitely not be used as boolean operators. o Binary compatibility for matching versions.
This is an Erlang solution to "The Santa Claus problem", % as discussed by Simon Peyton Jones (with a Haskell solution using % Software Transactional Memory) in "Beautiful code". % He quotes J.A.Trono "A new exercise in concurrency", SIGCSE 26:8-10, 1994.
With the advent of multi-core processors concurrent programming is becoming indispensable. Scala's primary concurrency construct is actors. Actors are basically concurrent processes that communicate by exchanging messages. Actors can also be seen as a form of active objects where invoking a method corresponds to sending a message. The Scala Actors library provides both asynchronous and synchronous message sends (the latter are implemented by exchanging several asynchronous messages). Moreover, actors may communicate using futures where requests are handled asynchronously, but return a representation (the future) that allows to await the reply. This tutorial is mainly designed as a walk-through of several complete example programs Our first example consists of two actors that exchange a bunch of messages and then terminate. The first actor sends "ping" messages to the second actor, which in turn sends "pong" messages back (for each received "ping" message one "pong" message).
Dynamic Networks Everything I described so far is common to CSP (Communicating Sequential Processes) and the Actor model. Here’s what makes actors more general: Connections between actors are dynamic. Unlike processes in CSP, actors may establish communication channels dynamically. They may pass messages containing references to actors (or mailboxes). They can then send messages to those actors. Here’s a Scala example: receive { case (name: String, actor: Actor) => actor ! lookup(name) } The original message is a tuple combining a string and an actor object. The receiver sends the result of lookup(name) to the actor it has just learned about. Thus a new communication channel between the receiver and the unknown actor can be established at runtime. (In Kilim the same is possible by passing mailboxes via messages.)
The Java™ programming language made starting a new thread easier than ever before. But freeing your concurrent programs of obscure bugs is a different matter, and Java's programming model might not be the best available. A language called Erlang is getting some good press now in the areas of concurrency, distributed systems, and soft real-time systems.
Candygram is a Python implementation of Erlang concurrency primitives. Erlang is widely respected for its elegant built-in facilities for concurrent programming. This package attempts to emulate those facilities as closely as possible in Python. With Candygram, developers can send and receive messages between threads using semantics nearly identical to those in the Erlang language.
PARLEY is an API for writing Python programs that implement the Actor model of distributed systems, in which lightweight concurrent processes communicate through asynchronous message-passing.
This package is the backport of java.util.concurrent API, introduced in Java 5.0 and further refined in Java 6.0, to older Java platforms. The backport is based on public-domain sources from the JSR 166 CVS repository, the dl.util.concurrent package, and
A collection of Concurrent and Highly Scalable Utilities. These are intended as direct replacements for the java.util.* or java.util.concurrent.* collections but with better performance when many CPUs are using the collection concurrently.
S. Abramsky. Electronic Notes in Theoretical Computer Science, (2006)Proceedings of the Workshop "Essays on Algebraic Process Calculi" (APC 25)Proceedings of the Workshop "Essays on Algebraic Process Calculi" (APC 25).
D. Aumayr, S. Marr, E. Gonzalez Boix, and H. Mössenböck. Proceedings of the 16th ACM SIGPLAN International Conference on Managed Programming Languages and Runtimes, page 157--171. ACM, (October 2019)
J. Bezivin. OOPSLA '87: Conference proceedings on Object-oriented programming systems, languages and applications, page 394--405. New York, NY, USA, ACM, (1987)