Case Study: Actor Scheduler

- ~300 lines of C code

- scalable

- fast

- fair (starvation-free)

In computer science, the Actor model is a mathematical model of concurrent computation that treats "actors" as the universal primitives of concurrent digital computation: in response to a message that it receives, an actor can make local decisions, create more actors, send more messages, and determine how to respond to the next message received. The Actor model originated in 1973.^[1] It has been used both as a framework for a theoretical understanding of computation, and as the theoretical basis for several practical implementations of concurrent systems. The relationship of the model to other work is discussed in Indeterminacy in concurrent computation and Actor model and process calculi.

History

Main article: History of the Actor model

Unlike previous models of computation, the Actor model was inspired by physics including general relativity and quantum mechanics. It was also influenced by the programming languages Lisp, Simula and early versions of Smalltalk, as well as capability-based systems and packet switching. Its development was "motivated by the prospect of highly parallel computing machines consisting of dozens, hundreds or even thousands of independent microprocessors, each with its own local memory and communications processor, communicating via a high-performance communications network."^[2] Since that time, the advent of massive concurrency through multi-core computer architectures has rekindled interest in the Actor model.

Following Hewitt, Bishop, and Steiger's 1973 publication, Irene Greif developed an operational semantics for the Actors model as part of her doctoral research.^[3] Two years later, Henry Baker and Hewitt published a set of axiomatic laws for Actor systems.^[4] Other major milestones include William Clinger's dissertation, in 1981, introducing a denotational semantics based on power domains,^[2] and Gul Agha's 1985 dissertation which further developed a transition-based semantic model complementary to Clinger's.^[5] This resulted in the full development of actor model theory.

Major software implementation work was done by Russ Atkinson, Beppe Attardi, Henry Baker, Gerry Barber, Peter Bishop, Peter de Jong, Ken Kahn, Henry Lieberman, Carl Manning, Tom Reinhardt, Richard Steiger, and Dan Theriault, in the Message Passing Semantics Group at Massachusetts Institute of Technology (MIT). Research groups led by Chuck Seitz at California Institute of Technology (Caltech) and Bill Dally at MIT constructed computer architectures that further developed the message passing in the model. See Actor model implementation.

Research on the Actor model has been carried out at Caltech Computer Science, Kyoto University Tokoro Laboratory, MCC, MIT Artificial Intelligence Laboratory, SRI, Stanford University, University of Illinois at Urbana-Champaign Open Systems Laboratory, Pierre and Marie Curie University (University of Paris 6), University of Pisa, University of Tokyo Yonezawa Laboratory and elsewhere.

Fundamental concepts

The Actor model adopts the philosophy that everything is an actor. This is similar to the everything is an object philosophy used by some object-oriented programming languages, but differs in that object-oriented software is typically executed sequentially, while the Actor model is inherently concurrent.

An actor is a computational entity that, in response to a message it receives, can concurrently:

• • send a finite number of messages to other actors;

  • create a finite number of new actors;

  • designate the behavior to be used for the next message it receives.

There is no assumed sequence to the above actions and they could be carried out in parallel.

Decoupling the sender from communications sent was a fundamental advance of the Actor model enabling asynchronous communication and control structures as patterns of passing messages.^[6]

Recipients of messages are identified by address, sometimes called "mailing address". Thus an actor can only communicate with actors whose addresses it has. It can obtain those from a message it receives, or if the address is for an actor it has itself created.

The Actor model is characterized by inherent concurrency of computation within and among actors, dynamic creation of actors, inclusion of actor addresses in messages, and interaction only through direct asynchronous message passing with no restriction on message arrival order.

Formal systems

Over the years, several different formal systems have been developed which permit reasoning about systems in the Actor model. These include:

• Operational semantics^[3][7]

  • Laws for Actor systems^[4]

• Denotational semantics^[2][8]

  • Transition semantics^[5]

There are also formalisms that are not fully faithful to the Actor model in that they do not formalize the guaranteed delivery of messages including the following (See Attempts to relate Actor semantics to algebra and linear logic):

• • Several different Actor algebras^[9][10][11]

  • Linear logic^[12]

Applications

The Actors model can be used as a framework for modelling, understanding, and reasoning about, a wide range of concurrent systems. For example:

• • Electronic mail (e-mail) can be modeled as an Actor system. Accounts are modeled as Actors and email addresses as Actor addresses.

  • Web Services can be modeled with SOAP endpoints modeled as Actor addresses.

  • Objects with locks (e.g. as in Java and C#) can be modeled as a Serializer, provided that their implementations are such that messages can continually arrive (perhaps by being stored in an internal queue). A serializer is an important kind of Actor defined by the property that it is continually available to the arrival of new messages; every message sent to a serializer is guaranteed to arrive.

  • Testing and Test Control Notation (TTCN), both TTCN-2 and TTCN-3, follows Actor model rather closely. In TTCN, Actor is a test component: either parallel test component (PTC) or main test component (MTC). Test components can send and receive messages to and from remote partners (peer test components or test system interface), the latter being identified by its address. Each test component has a behaviour tree bound to it; test components run in parallel and can be dynamically created by parent test components. Built-in language constructs allow the definition of actions to be taken when an expected message is received from the internal message queue, like sending a message to another peer entity or creating new test components.

Models prior to the Actor model

The Actor model builds on previous models of computation.

Lambda calculus

The lambda calculus of Alonzo Church can be viewed as the earliest message passing programming language (see Hewitt, Bishop, and Steiger 1973; Abelson and Sussman 1985). For example, the lambda expression below implements a tree data structure when supplied with parameters for a leftSubTree and rightSubTree. When such a tree is given a parameter message "getLeft", it returns leftSubTree and likewise when given the message "getRight" it returns rightSubTree.

λ(leftSubTree,rightSubTree)

λ(message)

if (message == "getLeft") then leftSubTree

else if (message == "getRight") then rightSubTree

However, the semantics of the lambda calculus were expressed using variable substitution in which the values of parameters were substituted into the body of an invoked lambda expression. The substitution model is unsuitable for concurrency because it does not allow the capability of sharing of changing resources. Inspired by the lambda calculus, the interpreter for the programming language Lisp made use of a data structure called an environment so that the values of parameters did not have to be substituted into the body of an invoked lambda expression. This allowed for sharing of the effects of updating shared data structures but did not provide for concurrency.

Simula

Simula 67 pioneered using message passing for computation, motivated by discrete event simulation applications. These applications had become large and unmodular in previous simulation languages. At each time step, a large central program would have to go through and update the state of each simulation object that changed depending on the state of whichever simulation objects that it interacted with on that step. Kristen Nygaard and Ole-Johan Dahl developed the idea (first described in an IFIP workshop in 1967) of having methods on each object that would update its own local state based on messages from other objects. In addition they introduced a class structure for objects with inheritance. Their innovations considerably improved the modularity of programs.

However, Simula used coroutine control structure instead of true concurrency.

Smalltalk

Alan Kay was influenced by message passing in the pattern-directed invocation of Planner in developing Smalltalk-71. Hewitt was intrigued by Smalltalk-71 but was put off by the complexity of communication that included invocations with many fields including global, sender, receiver, reply-style, status, reply, operator selector, etc.

In 1972 Kay visited MIT and discussed some of his ideas for Smalltalk-72 building on the Logo work of Seymour Papert and the "little person" model of computation used for teaching children to program. However, the message passing of Smalltalk-72 was quite complex. Code in the language was viewed by the interpreter as simply a stream of tokens. As Dan Ingalls later described it:

The first (token) encountered (in a program) was looked up in the dynamic context, to determine the receiver of the subsequent message. The name lookup began with the class dictionary of the current activation. Failing there, it moved to the sender of that activation and so on up the sender chain. When a binding was finally found for the token, its value became the receiver of a new message, and the interpreter activated the code for that object's class.

Thus the message-passing model in Smalltalk-72 was closely tied to a particular machine model and programming-language syntax that did not lend itself to concurrency. Also, although the system was bootstrapped on itself, the language constructs were not formally defined as objects that respond to Eval messages (see discussion below). This led some to believe that a new mathematical model of concurrent computation based on message passing should be simpler than Smalltalk-72.

Subsequent versions of the Smalltalk language largely followed the path of using the virtual methods of Simula in the message-passing structure of programs. However Smalltalk-72 made primitives such as integers, floating point numbers, etc. into objects. The authors of Simula had considered making such primitives into objects but refrained largely for efficiency reasons. Java at first used the expedient of having both primitive and object versions of integers, floating point numbers, etc. The C# programming language (and later versions of Java, starting with Java 1.5) adopted the less elegant solution of using boxing and unboxing, a variant of which had been used earlier in some Lisp implementations.

The Smalltalk system went on to become very influential, innovating in bitmap displays, personal computing, the class browser interface, and many other ways. For details see Kay's The Early History of Smalltalk^[13]. Meanwhile the Actor efforts at MIT remained focused on developing the science and engineering of higher level concurrency. (See the paper by Jean-Pierre Briot for ideas that were developed later on how to incorporate some kinds of Actor concurrency into later versions of Smalltalk.)

Petri nets

Prior to the development of the Actor model, Petri nets were widely used to model nondeterministic computation. However, they were widely acknowledged to have an important limitation: they modeled control flow but not data flow. Consequently they were not readily composable, thereby limiting their modularity. Hewitt pointed out another difficulty with Petri nets: simultaneous action. I.e., the atomic step of computation in Petri nets is a transition in which tokens simultaneously disappear from the input places of a transition and appear in the output places. The physical basis of using a primitive with this kind of simultaneity seemed questionable to him. Despite these apparent difficulties, Petri nets continue to be a popular approach to modelling concurrency, and are still the subject of active research.

Threads, locks, and buffers (channels)

Prior to the Actor model, concurrency was defined in low-level machine terms of threads, locks and buffers(channels). It certainly is the case that implementations of the Actor model typically make use of these hardware capabilities. However, there is no reason that the model could not be implemented directly in hardware without exposing any hardware threads and locks. Also, there is no necessary relationship between the number of Actors, threads, and locks that might be involved in a computation. Implementations of the Actor model are free to make use of threads and locks in any way that is compatible with the laws for Actors.

Message-passing semantics

The Actor model is about the semantics of message passing.

Unbounded nondeterminism controversy

Arguably, the first concurrent programs were interrupt handlers. During the course of its normal operation, a computer needed to be able to receive information from outside (characters from a keyboard, packets from a network, etc.). So when the information arrived, execution of the computer was "interrupted" and special code called an interrupt handler was called to put the information in a buffer where it could be subsequently retrieved.

In the early 1960s, interrupts began to be used to simulate the concurrent execution of several programs on a single processor.^[14] Having concurrency with shared memory gave rise to the problem of concurrency control. Originally, this problem was conceived as being one of mutual exclusion on a single computer. Edsger Dijkstra developed semaphores and later, between 1971 and 1973^[15], Tony Hoare^[16] and Per Brinch Hansen^[17] developed monitors to solve the mutual exclusion problem. However, neither of these solutions provided a programming-language construct that encapsulated access to shared resources. This encapsulation was later accomplished by the serializer construct ([Hewitt and Atkinson 1977, 1979] and [Atkinson 1980]).

The first models of computation (e.g. Turing machines, Post productions, the lambda calculus, etc.) were based on mathematics and made use of a global state to represent a computational step (later generalized in [McCarthy and Hayes 1969] and [Dijkstra 1976] see Event orderings versus global state). Each computational step was from one global state of the computation to the next global state. The global state approach was continued in automata theory for finite state machines and push down stack machines, including their nondeterministic versions. Such nondeterministic automata have the property of bounded nondeterminism; that is, if a machine always halts when started in its initial state, then there is a bound on the number of states in which it halts.

Edsger Dijkstra further developed the nondeterministic global state approach. Dijkstra's model gave rise to a controversy concerning unbounded nondeterminism. Unbounded nondeterminism (also called unbounded indeterminacy), is a property of concurrency by which the amount of delay in servicing a request can become unbounded as a result of arbitration of contention for shared resources while still guaranteeing that the request will eventually be serviced. Hewitt argued that the Actor model should provide the guarantee of service. In Dijkstra's model, although there could be an unbounded amount of time between the execution of sequential instructions on a computer, a (parallel) program that started out in a well defined state could terminate in only a bounded number of states [Dijkstra 1976]. Consequently, his model could not provide the guarantee of service. Dijkstra argued that it was impossible to implement unbounded nondeterminism.

Hewitt argued otherwise: there is no bound that can be placed on how long it takes a computational circuit called an arbiter to settle (see metastability in electronics). Arbiters are used in computers to deal with the circumstance that computer clocks operate asynchronously with input from outside, e.g. keyboard input, disk access, network input, etc. So it could take an unbounded time for a message sent to a computer to be received and in the meantime the computer could traverse an unbounded number of states.

The Actor Model features unbounded nondeterminism which was captured in a mathematical model by Will Clinger using domain theory.^[2] There is no global state in the Actor model.

Direct communication and asynchrony

Messages in the Actor model are not necessarily buffered. This was a sharp break with previous approaches to models of concurrent computation. The lack of buffering caused a great deal of misunderstanding at the time of the development of the Actor model and is still a controversial issue. Some researchers argued that the messages are buffered in the "ether" or the "environment". Also, messages in the Actor model are simply sent (like packets in IP); there is no requirement for a synchronous handshake with the recipient.

Actor creation plus addresses in messages means variable topology

A natural development of the Actor model was to allow addresses in messages. Influenced by packet switched networks [1961 and 1964], Hewitt proposed the development of a new model of concurrent computation in which communications would not have any required fields at all: they could be empty. Of course, if the sender of a communication desired a recipient to have access to addresses which the recipient did not already have, the address would have to be sent in the communication.

A computation might need to send a message to a recipient from which it would later receive a response. The way to do this is to send a communication which has the message along with the address of another actor called the resumption (sometimes also called continuation or stack frame) along with the message. The recipient could then cause a response message to be sent to the resumption.

Actor creation plus the inclusion of the addresses of actors in messages means that Actors have a potentially variable topology in their relationship to one another much as the objects in Simula also had a variable topology in their relationship to one another.

Inherently concurrent

As opposed to the previous approach based on composing sequential processes, the Actor model was developed as an inherently concurrent model. In the Actor model sequentiality was a special case that derived from concurrent computation as explained in Actor model theory.

No requirement on order of message arrival

Hewitt argued against adding the requirement that messages must arrive in the order in which they are sent to the Actor. If output message ordering is desired, then it can be modeled by a queue Actor that provides this functionality. Such a queue Actor would queue the messages that arrived so that they could be retrieved in FIFO order. So if an Actor X sent a message M1 to an Actor Y, and later X sent another message M2 to Y, there is no requirement that M1 arrives at Y before M2.

In this respect the Actor model mirrors packet switching systems which do not guarantee that packets must be received in the order sent. Not providing the order of delivery guarantee allows packet switching to buffer packets, use multiple paths to send packets, resend damaged packets, and to provide other optimizations.

For example, Actors are allowed to pipeline the processing of messages. What this means is that in the course of processing a message M1, an Actor can designate the behavior to be used to process the next message, and then in fact begin processing another message M2 before it has finished processing M1. Just because an Actor is allowed to pipeline the processing of messages does not mean that it must pipeline the processing. Whether a message is pipelined is an engineering tradeoff. How would an external observer know whether the processing of a message by an Actor has been pipelined? There is no ambiguity in the definition of an Actor created by the possibility of pipelining. Of course, it is possible to perform the pipeline optimization incorrectly in some implementations, in which case unexpected behavior may occur.

Locality

Another important characteristic of the Actor model is locality.

Locality means that in processing a message an Actor can send messages only to addresses that it receives in the message, addresses that it already had before it received the message and addresses for Actors that it creates while processing the message. (But see Synthesizing Addresses of Actors.)

Also locality means that there is no simultaneous change in multiple locations. In this way it differs from some other models of concurrency, e.g., the Petri net model in which tokens are simultaneously removed from multiple locations and placed in other locations.

Composing Actor Systems

The idea of composing Actor systems into larger ones is an important aspect of modularity that was developed in Gul Agha's doctoral dissertation,^[5], developed later by Gul Agha, Ian Mason, Scott Smith, and Carolyn Talcott.^[7]

Behaviors

A key innovation was the introduction of behavior specified as a mathematical function to express what an Actor does when it processes a message including specifying a new behavior to process the next message that arrives. Behaviors provided a mechanism to mathematically model the sharing in concurrency.

Behaviors also freed the Actor model from implementation details, e.g., the Smalltalk-72 token stream interpreter. However, it is critical to understand that the efficient implementation of systems described by the Actor model require extensive optimization. See Actor model implementation for details.

Modeling other concurrency systems

Other concurrency systems (e.g. process calculi) can be modeled in the Actor model using a two-phase commit protocol.^[18]

Computational Representation Theorem

There is a Computational Representation Theorem in the Actor model for systems which are closed in the sense that they do not receive communications from outside. The mathematical denotation denoted by a closed system S. is constructed increasingly better approximations from an initial behavior called ⊥_S using a behavior-approximating function progression_S to construct a denotation (meaning ) for S as follows [Hewitt 2008; Clinger 1981]:

Denote_S ≡ ⊔_i∈ω progression_Sⁱ(⊥_S)

In this way, S can be mathematically characterized in terms of all its possible behaviors (including those involving unbounded nondeterminism). Although Denote_S is not an implementation of S, it can be used to prove a generalization of the Church-Turing-Rosser-Kleene thesis [Kleene 1943]:

Enumeration Theorem: If the primitive Actors of a closed Actor system are effective, then its possible outputs are recursively enumerable.

Proof: Follows immediately from the Representation Theorem.

Relationship to mathematical logic

The development of the Actor model has an interesting relationship to mathematical logic. One of the key motivations for its development was to understand and deal with the control structure issues that arose in development of the Planner programming language. Once the Actor model was initially defined, an important challenge was to understand the power of the model relative to Robert Kowalski's thesis that "computation can be subsumed by deduction". Kowalski's thesis turned out to be false for the concurrent computation in the Actor model (see Indeterminacy in concurrent computation). This result is still somewhat controversial and it reversed previous expectations because Kowalski's thesis is true for sequential computation and even some kinds of parallel computation, e.g. the lambda calculus.

Nevertheless attempts were made to extend logic programming to concurrent computation. However, Hewitt and Agha [1991] claimed that the resulting systems were not deductive in the following sense: computational steps of the concurrent logic programming systems do not follow deductively from previous steps (see Indeterminacy in concurrent computation).

Migration

Migration in the Actor model is the ability of Actors to change locations. E.g., in his dissertation, Aki Yonezawa modeled a post office that customer Actors could enter, change locations within while operating, and exit. An Actor that can migrate can be modeled by having a location Actor that changes when the Actor migrates. However the faithfulness of this modeling is controversial and the subject of research.

Security

The security of Actors can be protected in the following ways:

• • hardwiring in which Actors are physically connected

  • hardware as in Burroughs B5000, Lisp machine, etc.

  • virtual machines as in Java virtual machine, Common Language Runtime, etc.

  • operating systems as in capability-based systems

  • signing and/or encryption of Actors and their addresses

Synthesizing addresses of actors

A delicate point in the Actor model is the ability to synthesize the address of an Actor. In some cases security can be used to prevent the synthesis of addresses (see Security). However, if an Actor address is simply a bit string then clearly it can be synthesized although it may be difficult or even infeasible to guess the address of an Actor if the bit strings are long enough. SOAP uses a URL for the address of an endpoint where an Actor can be reached. Since a URL is a character string, it can clearly be synthesized although encryption can make it virtually impossible to guess.

Synthesizing the addresses of Actors is usually modeled using mapping. The idea is to use an Actor system to perform the mapping to the actual Actor addresses. For example, on a computer the memory structure of the computer can be modeled as an Actor system that does the mapping. In the case of SOAP addresses, it's modeling the DNS and rest of the URL mapping.

Contrast with other models of message-passing concurrency

Robin Milner's initial published work on concurrency^[19] was also notable in that it was not based on composing sequential processes. His work differed from the Actor model because it was based on a fixed number of processes of fixed topology communicating numbers and strings using synchronous communication. The original Communicating Sequential Processes model^[20] published by Tony Hoare differed from the Actor model because it was based on the parallel composition of a fixed number of sequential processes connected in a fixed topology, and communicating using synchronous message-passing based on process names (see Actor model and process calculi history). Later versions of CSP abandoned communication based on process names in favor of anonymous communication via channels, an approach also used in Milner's work on the Calculus of Communicating Systems and the π-calculus.

These early models by Milner and Hoare both had the property of bounded nondeterminism. Modern, theoretical CSP ([Hoare 1985] and [Roscoe 2005]) explicitly provides unbounded nondeterminism.

Current importance

Forty years after the publication of Moore's Law, hardware development is furthering local and nonlocal massive concurrency. Local concurrency is enabled by new hardware for 64-bit multi-core (Platform 2015 Unveiled at IDF Spring 2005) microprocessors, multi-chip modules, and high performance interconnect. Nonlocal concurrency is being enabled by new hardware for wired and wireless broadbandpacket switched communications (see Wi-Fi and Ultra wideband). Both local and nonlocal storage capacities are growing exponentially.

According to Hewitt [2006], the Actor model faces issues in computer and communications architecture, concurrent programming languages, and Web Services including the following:

• • scalability: the challenge of scaling up concurrency both locally and nonlocally.

  • transparency: bridging the chasm between local and nonlocal concurrency. Transparency is currently a controversial issue. Some researchers^[who?] have advocated a strict separation between local concurrency using concurrent programming languages (e.g. Java and C#) from nonlocal concurrency using SOAP for Web services. Strict separation produces a lack of transparency that causes problems when it is desirable/necessary to change between local and nonlocal access to Web Services (see distributed computing).

  • inconsistency: Inconsistency is the norm because all very large knowledge systems about human information system interactions are inconsistent. This inconsistency extends to the documentation and specifications of very large systems (e.g. Microsoft Windows software, etc.), which are internally inconsistent.

Many of the ideas introduced in the Actor model are now also finding application in multi-agent systems for these same reasons [Hewitt 2006b 2007b]. The key difference is that agent systems (in most definitions) impose extra constraints upon the Actors, typically requiring that they make use of commitments and goals.

The Actor model is also being applied to client cloud computing ^[21].

Actor researchers

Important contributions to the semantics of Actors have been made by: Gul Agha, Beppe Attardi, Henry Baker, Will Clinger, Irene Greif, Carl Hewitt, Carl Manning, Ian Mason, Ugo Montanari, Maria Simi, Scott Smith, Carolyn Talcott, Prasanna Thati, and Aki Yonezawa.

Important contributions to the implementation of Actors have been made by: Bill Athas, Russ Atkinson, Beppe Attardi, Henry Baker, Gerry Barber, Peter Bishop, Nanette Boden, Jean-Pierre Briot, Bill Dally, Peter de Jong, Jessie Dedecker, Travis Desell, Ken Kahn, Carl Hewitt, Henry Lieberman, Carl Manning, Tom Reinhardt, Chuck Seitz, Richard Steiger, Dan Theriault, Mario Tokoro, Carlos Varela, Darrell Woelk.

Programming with Actors

A number of different programming languages employ the Actor model or some variation of it. These languages include:

Early Actor programming languages

• • Act 1, 2 and 3 ^[22][23]

  • Acttalk ^[24]

  • Ani ^[25]

  • Cantor ^[26]

  • Rosette^[27]

Later Actor programming languages

• ABCL

  • ActorScript

• AmbientTalk^[28]

• Axum^[29]

• E

• Erlang

• Io

• Ptolemy Project

• Rebeca Modeling Language

• Reia

• SALSA^[30]

• Scala^[31][32]

Actor libraries and frameworks

Actor libraries or frameworks have also been implemented to permit actor-style programming in languages that don't have actors built-in. Among these frameworks are:

• • Akka - A Java and Scala framework with Actors, STM & Transactors

  • Ateji PX - Ateji PX provides an Actor Model for Java

  • Korus - A Java parallel and distributed programming framework based on Actor Model

  • Kilim - a message-passing framework for Java^[33]

  • ActorFoundry - a Java library for Actor programming

  • Retlang for .NET

  • Jetlang for Java

  • Haskell-Actor for Haskell

  • GPars - the concurrency and actor library for Groovy (was GParallelizer)

  • PARLEY - The Python Actor Runtime Library

  • Termite Scheme - provides Erlang-like concurency for the Gambit implementation of Scheme

  • Theron - provides an Actor Model for C++.

See also

• Data flow

  • Special relativity (specifically, Relativity of simultaneity) and Quantum physics, for some physical motivation for the Actor model theory

• Multi-agent system

• Neural networks

• Scientific Community Metaphor

• Communicating sequential processes

References

• 1. ^ Carl Hewitt; Peter Bishop and Richard Steiger (1973). A Universal Modular Actor Formalism for Artificial Intelligence. IJCAI.

  2. ^ ^{a b c d} William Clinger (June 1981). Foundations of Actor Semantics. Mathematics Doctoral Dissertation. MIT. https://dspace.mit.edu/handle/1721.1/6935.

  3. ^ ^{a b} Irene Greif (August 1975). Semantics of Communicating Parallel Processes. EECS Doctoral Dissertation. MIT.

  4. ^ ^{a b} Henry Baker; Carl Hewitt (August 1977). Laws for Communicating Parallel Processes. IFIP.

  5. ^ ^{a b c} Gul Agha (1986). Actors: A Model of Concurrent Computation in Distributed Systems. Doctoral Dissertation. MIT Press. https://dspace.mit.edu/handle/1721.1/6952.

  6. ^ Carl Hewitt. Viewing Control Structures as Patterns of Passing Messages Journal of Artificial Intelligence. June 1977.

  7. ^ ^{a b} Gul Agha; Ian Mason, Scott Smith, and Carolyn Talcott (January 1993). "A Foundation for Actor Computation". Journal of Functional Programming.

  8. ^ Carl Hewitt (2006-04-27) (PDF). What is Commitment? Physical, Organizational, and Social. COIN@AAMAS. http://www.pcs.usp.br/~coin-aamas06/10_commitment-43_16pages.pdf.

  9. ^ Mauro Gaspari; Gianluigi Zavattaro (May 1997). An Algebra of Actors. Technical Report UBLCS-97-4. University of Bologna.

  10. ^ M. Gaspari; G. Zavattaro (1999). An Algebra of Actors. Formal Methods for Open Object Based Systems.

  11. ^ Gul Agha; Prasanna Thati (2004) (PDF). An Algebraic Theory of Actors and Its Application to a Simple Object-Based Language. From OO to FM (Dahl Festschrift) LNCS 2635. http://formal.cs.uiuc.edu/papers/ATactors_festschrift.pdf.

  12. ^ John Darlington; Y. K. Guo (1994). Formalizing Actors in Linear Logic. International Conference on Object-Oriented Information Systems.

  13. ^ Kay, Alan (March 1993). "The Early History of Smalltalk" (PDF). ACM SIGPLAN 28 (3): 69–75. doi:10.1145/155360.155364. http://www.smalltalk.org/downloads/papers/SmalltalkHistoryHOPL.pdf.

  14. ^ Brinch-Hansen, Per (2002). The Origins of Concurrent Programming: From Semaphores to Remote Procedure Calls. Springer. ISBN 978-0387954011.

  15. ^ Per Brinch Hansen, Monitors and Concurrent Pascal: A Personal History, Comm. ACM 1996, pp 121-172

  16. ^ C.A.R. Hoare, Monitors: An Operating System Structuring Concept, Comm. ACM Vol. 17, No. 10. October 1974, pp. 549-557

  17. ^ Brinch Hansen, P., Operating System Principles, Prentice-Hall, July 1973.

  18. ^ Frederick Knabe. A Distributed Protocol for Channel-Based Communication with Choice PARLE 1992.

  19. ^ Robin Milner. Processes: A Mathematical Model of Computing Agents in Logic Colloquium 1973.

  20. ^ C.A.R. Hoare. Communicating sequential processes CACM. August 1978.

  21. ^ Carl Hewitt (September/October 2008). "ORGs for Scalable, Robust, Privacy-Friendly Client Cloud Computing". IEEE Internet Computing 12 (5).

  22. ^ Henry Lieberman (June 1981). A Preview of Act 1. MIT AI memo 625. ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-625.pdf.

  23. ^ Henry Lieberman (June 1981). Thinking About Lots of Things at Once without Getting Confused: Parallelism in Act 1. MIT AI memo 626. ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-626.pdf.

  24. ^ Jean-Pierre Briot. Acttalk: A framework for object-oriented concurrent programming-design and experience 2nd France-Japan workshop. 1999.

  25. ^ Ken Kahn. A Computational Theory of Animation MIT EECS Doctoral Dissertation. August 1979.

  26. ^ William Athas and Nanette Boden Cantor: An Actor Programming System for Scientific Computing in Proceedings of the NSF Workshop on Object-Based Concurrent Programming. 1988. Special Issue of SIGPLAN Notices.

  27. ^ Darrell Woelk. Developing InfoSleuth Agents Using Rosette: An Actor Based Language Proceedings of the CIKM '95 Workshop on Intelligent Information Agents. 1995.

  28. ^ Dedecker J., Van Cutsem T., Mostinckx S., D'Hondt T., De Meuter W. Ambient-oriented Programming in AmbientTalk. In “Proceedings of the 20th European Conference on Object-Oriented Programming (ECOOP), Dave Thomas (Ed.), Lecture Notes in Computer Science Vol. 4067, pp. 230-254, Springer-Verlag.”, 2006

  29. ^ http://www.eweek.com/c/a/Application-Development/Microsoft-Cooking-Up-New-Parallel-Programming-Language-Axum-868670/

  30. ^ Carlos Varela and Gul Agha (2001). "Programming Dynamically Reconfigurable Open Systems with SALSA". ACM SIGPLAN Notices. OOPSLA’2001 Intriguing Technology Track Proceedings 36.

  31. ^ Philipp Haller and Martin Odersky (September 2006) (PDF). Event-Based Programming without Inversion of Control. Proc. JMLC 2006. http://lampwww.epfl.ch/~odersky/papers/jmlc06.pdf.

  32. ^ Philipp Haller and Martin Odersky (January 2007) (PDF). Actors that Unify Threads and Events. Technical report LAMP 2007. http://lamp.epfl.ch/~phaller/doc/haller07coord.pdf.

  33. ^ Srinivasan, Sriram; Alan Mycroft (2008). "Kilim: Isolation-Typed Actors for Java" (PDF). European Conference on Object Oriented Programming ECOOP 2008. Cyprus. http://www.malhar.net/sriram/kilim/kilim_ecoop08.pdf. Retrieved 2008-07-24. .

Further reading

• • Stephen Kleene Recursive Predicates and Quantifiers American Mathematical Society Transactions. 1943.

  • Paul Baran. On Distributed Communications Networks IEEE Transactions on Communications Systems. March 1964.

  • Peter Landin. A Generalization of Jumps and Labels Report. UNIVAC Systems Programming Research. August 1965. Reprinted in Higher Order and Symbolic Computation. 1998.

  • Edsger Dijkstra Solution of a Problem in Concurrent Programming Control CACM. 1965.

  • Jack Dennis and Earl Van Horn. Programming Semantics for Multiprogrammed Computations CACM. March 1966.

  • Ole-Johan Dahl and Kristen Nygaard. Class and subclass declarations IFIP TC2 Conference on Simulation Programming Languages. May 1967.

  • Carl Hewitt. PLANNER: A Language for Proving Theorems in Robots IJCAI 1969

  • William A. Woods. Transition network grammars for natural language analysis CACM. 1970.

  • Terry Winograd. Procedures as a Representation for Data in a Computer Program for Understanding Natural Language MIT AI TR-235. January 1971.

  • Carl Hewitt. Procedural Embedding of Knowledge In Planner IJCAI 1971.

  • G.M. Birtwistle, Ole-Johan Dahl, B. Myhrhaug and Kristen Nygaard. SIMULA Begin Auerbach Publishers Inc, 1973.

  • Daniel Bobrow: A Model for Control Structures for Artificial Intelligence Programming Languages IJCAI 1973.

  • Carl Hewitt, et al. Actor Induction and Meta-evaluation Conference Record of ACM Symposium on Principles of Programming Languages, January 1974.

  • Carl Hewitt, et al. Behavioral Semantics of Nonrecursive Control Structure Proceedings of Colloque sur la Programmation, April 1974.

  • Irene Greif and Carl Hewitt. Actor Semantics of PLANNER-73 Conference Record of ACM Symposium on Principles of Programming Languages. January 1975.

  • Carl Hewitt. How to Use What You Know IJCAI. September, 1975.

  • Alan Kay and Adele Goldberg. Smalltalk-72 Instruction Manual Xerox PARC Memo SSL-76-6. May 1976.

  • Edsger Dijkstra. A discipline of programming Prentice Hall. 1976.

  • Carl Hewitt and Henry Baker Actors and Continuous Functionals Proceeding of IFIP Working Conference on Formal Description of Programming Concepts. August 1–5, 1977.

  • Henry Baker and Carl Hewitt The Incremental Garbage Collection of Processes Proceeding of the Symposium on Artificial Intelligence Programming Languages. SIGPLAN Notices 12, August 1977.

  • Gilles Kahn and David MacQueen. Coroutines and networks of parallel processes IFIP. 1977

  • Aki Yonezawa Specification and Verification Techniques for Parallel Programs Based on Message Passing Semantics MIT EECS Doctoral Dissertation. December 1977.

  • Henry Baker. Actor Systems for Real-Time Computation MIT EECS Doctoral Dissertation. January 1978.

  • Carl Hewitt and Russ Atkinson. Synchronization in Actor Systems Proceedings of the 4th ACM SIGACT-SIGPLAN symposium on Principles of programming languages. 1977

  • Carl Hewitt and Russ Atkinson. Specification and Proof Techniques for Serializers IEEE Journal on Software Engineering. January 1979.

  • Ken Kahn. A Computational Theory of Animation MIT EECS Doctoral Dissertation. August 1979.

  • Carl Hewitt, Beppe Attardi, and Henry Lieberman. Delegation in Message Passing Proceedings of First International Conference on Distributed Systems Huntsville, AL. October 1979.

  • Nissim Francez, C.A.R. Hoare, Daniel Lehmann, and Willem-Paul de Roever. Semantics of nondetermiism, concurrency, and communication Journal of Computer and System Sciences. December 1979.

  • George Milne and Robin Milner. Concurrent processes and their syntax JACM. April 1979.

  • Russ Atkinson. Automatic Verification of Serializers MIT Doctoral Dissertation. June, 1980.

  • Bill Kornfeld and Carl Hewitt. The Scientific Community Metaphor IEEE Transactions on Systems, Man, and Cybernetics. January 1981.

  • Bill Kornfeld. Parallelism in Problem Solving MIT EECS Doctoral Dissertation. August 1981.

  • Daniel Theriault. A Primer for the Act-1 Language MIT AI memo 672. April 1982.

  • Daniel Theriault. Issues in the Design and Implementation of Act 2 MIT AI technical report 728. June 1983.

  • Henry Lieberman. An Object-Oriented Simulator for the Apiary Conference of the American Association for Artificial Intelligence, Washington, D. C., August 1983

  • Carl Hewitt and Peter de Jong. Analyzing the Roles of Descriptions and Actions in Open Systems Proceedings of the National Conference on Artificial Intelligence. August 1983.

  • Carl Hewitt and Henry Lieberman. Design Issues in Parallel Architecture for Artificial Intelligence MIT AI memo 750. Nov. 1983.

  • Daniel Ingalls. The Evolution of the Smalltalk Virtual Machine in Smalltalk-80: Bits of History, Words of Advice. Addison Wesley. 1983.

  • Hal Abelson, Gerald Jay Sussman and Julie Sussman, Structure and Interpretation of Computer Programs MIT Press and McGraw-Hill, 1985.

  • C.A.R. Hoare. Communicating Sequential Processes Prentice Hall. 1985.

  • Carl Hewitt. The Challenge of Open Systems Byte Magazine. April 1985. Reprinted in The foundation of artificial intelligence---a sourcebook Cambridge University Press. 1990.

  • Carl Manning. Traveler: the actor observatory ECOOP 1987. Also appears in Lecture Notes in Computer Science, vol. 276.

  • William Athas and Charles Seitz Multicomputers: message-passing concurrent computers IEEE Computer August 1988.

  • William Athas and Nanette Boden Cantor: An Actor Programming System for Scientific Computing in Proceedings of the NSF Workshop on Object-Based Concurrent Programming. 1988. Special Issue of SIGPLAN Notices.

  • Jean-Pierre Briot. From objects to actors: Study of a limited symbiosis in Smalltalk-80 Rapport de Recherche 88-58, RXF-LITP, Paris, France, September 1988

  • William Dally and Wills, D. Universal mechanisms for concurrency PARLE 1989.

  • W. Horwat, A. Chien, and W. Dally. Experience with CST: Programming and Implementation PLDI. 1989.

  • Carl Hewitt. Towards Open Information Systems Semantics Proceedings of 10th International Workshop on Distributed Artificial Intelligence. October 23–27, 1990. Bandera, Texas.

  • Akinori Yonezawa, Ed. ABCL: An Object-Oriented Concurrent System MIT Press. 1990.

  • K. Kahn and Vijay A. Saraswat, "Actors as a special case of concurrent constraint (logic) programming", in SIGPLAN Notices, October 1990. Describes Janus.

  • Carl Hewitt. Open Information Systems Semantics Journal of Artificial Intelligence. January 1991.

  • Carl Hewitt and Jeff Inman. DAI Betwixt and Between: From "Intelligent Agents" to Open Systems Science IEEE Transactions on Systems, Man, and Cybernetics. Nov./Dec. 1991.

  • Carl Hewitt and Gul Agha. Guarded Horn clause languages: are they deductive and Logical? International Conference on Fifth Generation Computer Systems, Ohmsha 1988. Tokyo. Also in Artificial Intelligence at MIT, Vol. 2. MIT Press 1991.

  • William Dally, et al. The Message-Driven Processor: A Multicomputer Processing Node with Efficient MechanismsIEEE Micro. April 1992.

  • S. Miriyala, G. Agha, and Y.Sami. Visulatizing actor programs using predicate transition nets Journal of Visual Programming. 1992.

  • Alan Kay. The Early History of Smalltalk The second ACM conference on history of programming languages. 1993.

  • Carl Hewitt and Carl Manning. Negotiation Architecture for Large-Scale Crisis Management AAAI-94 Workshop on Models of Conflict Management in Cooperative Problem Solving. Seattle, WA. Aug. 4, 1994.

  • Darrell Woelk. Developing InfoSleuth Agents Using Rosette: An Actor Based Language Proceedings of the CIKM '95 Workshop on Intelligent Information Agents. 1995.

  • Carl Hewitt and Carl Manning. Synthetic Infrastructures for Multi-Agency Systems Proceedings of ICMAS '96. Kyoto, Japan. December 8–13, 1996.

  • S. Frolund. Coordinating Distributed Objects: An Actor-Based Approach for Synchronization MIT Press. November 1996.

  • W. Kim. ThAL: An Actor System for Efficient and Scalable Concurrent Computing PhD thesis. University of Illinois at Urbana Champaign. 1997.

  • Jean-Pierre Briot. Acttalk: A framework for object-oriented concurrent programming-design and experience 2nd France-Japan workshop. 1999.

  • N. Jamali, P. Thati, and G. Agha. An actor based architecture for customizing and controlling agent ensembles IEEE Intelligent Systems. 14(2). 1999.

  • Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Nielsen, Satish Thatte, Dave Winer. Simple Object Access Protocol (SOAP) 1.1 W3C Note. May 2000.

  • M. Astley, D. Sturman, and G. Agha. Customizable middleware for modular distributed software CACM. 44(5) 2001.

  • Carlos Varela. Worldwide Computing with Universal Actors: Linguistic Abstractions for Naming, Migration, and Coordination PhD thesis. U. of Illinois at Urbana-Champaign. 2001.

  • N. Venkatasubramanian, C. Talcott, and G. Agha. A formal model for reasoning about adaptive QoS-enabled middleware Formal Methods Europe (FME). 2001.

  • Edward Lee, S. Neuendorffer, and M. Wirthlin. Actor-oriented design of embedded hardware and software systems Journal of circuits, systems, and computers. 2002.

  • P. Thati, R. Ziaei, and G. Agha. A Theory of May Testing for Actors Formal Methods for Open Object-based Distributed Systems. March 2002.

  • P. Thati, R. Ziaei, and G. Agha. A theory of may testing for asynchronous calculi with locality and no name matching Algebraic Methodology and Software Technology. Springer Verlag. September 2002. LNCS 2422.

  • Gul Agha and Carlos Varela. Worldwide Computing Middleware Practical Handbook on Internet Computing. CRC Press, 2004.

  • Stephen Neuendorffer. Actor-Oriented Metaprogramming PhD Thesis. University of California, Berkeley. December, 2004

  • Carl Hewitt (2006a) The repeated demise of logic programming and why it will be reincarnated What Went Wrong and Why: Lessons from AI Research and Applications. Technical Report SS-06-08. AAAI Press. March 2006.

  • Carl Hewitt (2006b) What is Commitment? Physical, Organizational, and Social COIN@AAMAS. April 27, 2006b.

  • Carl Hewitt (2007a) What is Commitment? Physical, Organizational, and Social (Revised) Pablo Noriega .et al. editors. LNAI 4386. Springer-Verlag. 2007.

  • Carl Hewitt (2007b) Large-scale Organizational Computing requires Unstratified Paraconsistency and Reflection COIN@AAMAS'07.

External links

• • A now dated set of speculations by Paul Mackay can be found at Why has the actor model not succeeded?

  • JavAct - a Java library for programming concurrent, distributed, and mobile applications using the actor model (and open implementation principles).

  • Functional Java - a Java library of that includes an implementation of concurrent actors with code examples in standard Java and Java 7 BGGA style.

  • ActorFoundry - a Java-based library for Actor programming. The familiar Java syntax, an ant build file and a bunch of example make the entry barrier very low.

  • ActiveJava - a prototype Java language extension for Actor programming.

In computer science, a non-blocking algorithm ensures that threads competing for a shared resource do not have their execution indefinitely postponed by mutual exclusion. A non-blocking algorithm is lock-free if there is guaranteed system-wide progress; wait-free if there is also guaranteed per-thread progress.

Literature up to the turn of the 21st century used "non-blocking" synonymously with lock-free. However, since 2003,^[1] the term has been weakened to only prevent progress-blocking interactions with a preemptive scheduler. In modern usage, therefore, an algorithm is non-blocking if the suspension of one or more threads will not stop the potential progress of the remaining threads. They are designed to avoid requiring a critical section. Often, these algorithms allow multiple processes to make progress on a problem without ever blocking each other. For some operations, these algorithms provide an alternative to locking mechanisms.

[edit] Motivation

Main article: The problems with locks

The traditional approach to multi-threaded programming is to use locks to synchronize access to shared resources. Synchronization primitives such as mutexes, semaphores, and critical sections are all mechanisms by which a programmer can ensure that certain sections of code do not execute concurrently if doing so would corrupt shared memory structures. If one thread attempts to acquire a lock that is already held by another thread, the thread will block until the lock is free.

Blocking a thread is undesirable for many reasons. An obvious reason is that while the thread is blocked, it cannot accomplish anything. If the blocked thread is performing a high-priority or real-time task, it is highly undesirable to halt its progress. Other problems are less obvious. Certain interactions between locks can lead to error conditions such as deadlock, livelock, and priority inversion. Using locks also involves a trade-off between coarse-grained locking, which can significantly reduce opportunities for parallelism, and fine-grained locking, which requires more careful design, increases overhead and is more prone to bugs.

Non-blocking algorithms are also safe for use in interrupt handlers: even though the preempted thread cannot be resumed, progress is still possible without it. In contrast, global data structures protected by mutual exclusion cannot safely be accessed in a handler, as the preempted thread may be the one holding the lock.

Non-blocking algorithms have the potential to prevent priority inversion, as no thread is forced to wait for a suspended thread to complete. However, as livelock is still possible, threads have to wait when they encounter contention; hence, priority inversion is still possible depending upon the contention management system used. Lock-free algorithms, below, avoid priority inversion.

[edit] Implementation

With few exceptions, non-blocking algorithms use atomic read-modify-write primitives that the hardware must provide, the most notable of which is compare and swap (CAS). Critical sections are almost always implemented using standard interfaces over these primitives. Until recently, all non-blocking algorithms had to be written "natively" with the underlying primitives to achieve acceptable performance. However, the emerging field of software transactional memory promises standard abstractions for writing efficient non-blocking code.

Much research has also been done in providing basic data structures such as stacks, queues, sets, and hash tables. These allow programs to easily exchange data between threads asynchronously.

Additionally, some data structures are weak enough to be implemented without special atomic primitives. These exceptions include:

• • single-reader single-writer ring buffer FIFO

  • Read-copy-update with a single writer and any number of readers. (The readers are wait-free; the writer is usually wait-free, until it needs to reclaim memory).

[edit] Wait-freedom

Wait-freedom is the strongest non-blocking guarantee of progress, combining guaranteed system-wide throughput with starvation-freedom. An algorithm is wait-free if every operation has a bound on the number of steps the algorithm will take before the operation completes.

It was shown in the 1980s^[2] that all algorithms can be implemented wait-free, and many transformations from serial code, called universal constructions, have been demonstrated. However, the resulting performance does not in general match even naïve blocking designs. It has also been shown^[3] that the widely-available atomic conditional primitives, CAS and LL/SC, cannot provide starvation-free implementations of many common data structures without memory costs growing linearly in the number of threads. Wait-free algorithms are therefore rare, both in research and in practice.

[edit] Lock-freedom

Lock-freedom allows individual threads to starve but guarantees system-wide throughput. An algorithm is lock-free if it satisfies that when the program threads are run sufficiently long at least one of the threads make progress (for some sensible definition of progress). All wait-free algorithms are lock-free.

In general, a lock-free algorithm can run in four phases: completing one's own operation, assisting an obstructing operation, aborting an obstructing operation, and waiting. Completing one's own operation is complicated by the possibility of concurrent assistance and abortion, but is invariably the fastest path to completion.

The decision about when to assist, abort or wait when an obstruction is met is the responsibility of a contention manager. This may be very simple (assist higher priority operations, abort lower priority ones), or may be more optimized to achieve better throughput, or lower the latency of prioritized operations.

Correct concurrent assistance is typically the most complex part of a lock-free algorithm, and often very costly to execute: not only does the assisting thread slow down, but thanks to the mechanics of shared memory, the thread being assisted will be slowed, too, if it is still running.

[edit] Obstruction-freedom

Obstruction-freedom is possibly the weakest natural non-blocking progress guarantee. An algorithm is obstruction-free if at any point, a single thread executed in isolation (i.e., with all obstructing threads suspended) for a bounded number of steps will complete its operation. All lock-free algorithms are obstruction-free.

Obstruction-freedom demands only that any partially-completed operation can be aborted and the changes made rolled back. Dropping concurrent assistance can often result in much simpler algorithms that are easier to validate. Preventing the system from continually live-locking is the task of a contention manager.

Obstruction-freedom is also called optimistic concurrency control.

Some obstruction-free algorithms use a pair of "consistency markers" in the data structure. Processes reading the data structure first read one consistency marker, then read the relevant data into an internal buffer, then read the other marker, and then compare the markers. The data is consistent if the two markers are identical. Markers may be non-identical when the read is interrupted by another process updating the data structure. In such a case, the process discards the data in the internal buffer and tries again.

[edit] See also

• ABA problem

• Compare-and-swap

• Concurrency control

• Deadlock

• Linearizability

• Load-Link/Store-Conditional

• Lock (software engineering)

• Memory barrier

• Mutual exclusion

• Pre-emptive multitasking

• Priority inversion

• Read-copy-update

• Resource starvation

• Room synchronization

• Software transactional memory

• Partitioned global address space

[edit] References

• 1. ^ M. Herlihy, V. Luchangco and M. Moir. "Obstruction-Free Synchronization: Double-Ended Queues as an Example." 23rd International Conference on Distributed Computing Systems, 2003, p.522.

  2. ^ Maurice P. Herlihy. "Impossibility and universality results for wait-free synchronization" Proceedings of the Seventh Annual ACM Symposium on Principles of Distributed Computing, 1988, pp. 276 - 290.

  3. ^ F. Fich, D. Hendler, N. Shavit. "On the inherent weakness of conditional synchronization primitives." 23rd Annual ACM Symposium on Principles of Distributed Computing, 2004, pp. 80-87.

[edit] External links

• • Article "Simple, Fast, and Practical Non-Blocking and Blocking Concurrent Queue Algorithms" by Maged M. Michael and Michael L. Scott

  • Discussion "Communication between Threads, without blocking"

  • Survey "Some Notes on Lock-Free and Wait-Free Algorithms" by Ross Bencina

  • java.util.concurrent.atomic – supports lock-free and thread-safe programming on single variables

  • System.Threading.Interlocked - Provides atomic operations for variables that are shared by multiple threads (.NET Framework)

• The Jail-Ust Container Library

• Practical lock-free data structures

  • Thesis "Efficient and Practical Non-Blocking Data Structures" (1414 KB) by Håkan Sundell

• WARPing - Wait-free techniques for Real-time Processing

  • Non-blocking Synchronization: Algorithms and Performance Evaluation. (1926 KB) by Yi Zhang

  • "Design and verification of lock-free parallel algorithms" by Hui Gao

  • "Asynchronous Data Sharing in Multiprocessor Real-Time Systems Using Process Consensus" by Jing Chen and Alan Burns

  • Discussion "lock-free versus lock-based algorithms"

  • Atomic Ptr Plus Project - collection of various lock-free synchronization primitives

  • AppCore: A Portable High-Performance Thread Synchronization Library - An Effective Marriage between Lock-Free and Lock-Based Algorithms

  • WaitFreeSynchronization and LockFreeSynchronization at the Portland Pattern Repository

• Multiplatform library with atomic operations

• A simple C++ lock-free LIFO implementation

  • Concurrent Data Structures - C++ library of various lock-free algorithms and GCs

  • 1024cores - a site devoted to lock-free, wait-free, obstruction-free and just scalable non-blocking synchronization algorithms and related topics