List of concurrency models

Question

Actor Model

I heard of message passing where there is no memory shared.

Is it about Erlang-style Actors?

Scala uses this idea in its Actors framework (thus, in Scala its not a part of the language, just a library) and it looks quite sexy!

In a few words Actors are objects that have no shared data at all, but can use async messages for interaction. Actors can be located on one or different hosts and use interesting error handling policy (when error happened - actor just dies).

You should read more on this in Erlang and Scala docs, its really straightforward and progressive approach!

Chapters 3, 17, 17.11:

http://www.scala-lang.org/sites/default/files/linuxsoft_archives/docu/files/ScalaByExample.pdf https://en.wikipedia.org/wiki/Actor_model

COM Threading (Concurrency) Model

• Single-Threaded Apartments
• Multi-Threaded Apartments
• Mixed Model Development

COM objects can be used in multiple threads of a process. The terms "Single- threaded Apartmen*t" (STA) and "*Multi-threaded Apartment" (MTA) are used to create a conceptual framework for describing the relationship between objects and threads, the concurrency relationships among objects, the means by which method calls are delivered to an object, and the rules for passing interface pointers among threads. Components and their clients choose between the following two apartment models presently supported by COM:

Single-threaded Apartment model (STA): One or more threads in a process use COM and calls to COM objects are synchronized by COM. Interfaces are marshaled between threads. A degenerate case of the single-threaded apartment model, where only one thread in a given process uses COM, is called the single-threading model. Previous Microsoft information and documentation has sometimes referred to the STA model simply as the "apartment model." Multi-threaded Apartment model (MTA): One or more threads use COM and calls to COM objects associated with the MTA are made directly by all threads associated with the MTA without any interposition of system code between caller and object. Because multiple simultaneous clients may be calling objects more or less simultaneously (simultaneously on multi-processor systems), objects must synchronize their internal state by themselves. Interfaces are not marshaled between threads. Previous Microsoft information and documentation has sometimes referred to this model as the "free-threaded model." Both the STA model and the MTA model can be used in the same process. This is sometimes referred to as a "mixed-model" process.

---

Other models according to Wikipedia

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

• Actor model
  • Object-capability model for security
• Petri nets
• Process calculi such as
  • Ambient calculus
  • Calculus of Communicating Systems (CCS)
  • Communicating Sequential Processes (CSP)
  • π-calculus

Futures

A future is a place-holder for the undetermined result of a (concurrent) computation. Once the computation delivers a result, the associated future is eliminated by globally replacing it with the result value. That value may be a future on its own.

Whenever a future is requested by a concurrent computation, i.e. it tries to access its value, that computation automatically synchronizes on the future by blocking until it becomes determined or failed.

There are four kinds of futures:

• concurrent futures stand for the result of a concurrent computation,
• lazy futures stand for the result of a computation that is only performed on request,
• promised futures stand for a value that is promised to be delivered later by explicit means,
• failed futures represent the result of a computation that terminated with an exception.

Software transactional memory

In computer science, software transactional memory (STM) is a concurrency control mechanism analogous to database transactions for controlling access to shared memory in concurrent computing. It is an alternative to lock-based synchronization. A transaction in this context is a piece of code that executes a series of reads and writes to shared memory. These reads and writes logically occur at a single instant in time; intermediate states are not visible to other (successful) transactions. The idea of providing hardware support for transactions originated in a 1986 paper and patent by Tom Knight[1]. The idea was popularized by Maurice Herlihy and J. Eliot B. Moss[2]. In 1995 Nir Shavit and Dan Touitou extended this idea to software-only transactional memory (STM)[3]. STM has recently been the focus of intense research and support for practical implementations is growing.