4 ms·
Synchronized requesting in Communicating Sequential Processes (CSP) [Hoare 1978] proceeds as follows: “Such communication occurs when one process names another
by ProfHewitt 7y ago
Synchronized requesting in Communicating Sequential Processes (CSP) [Hoare 1978] proceeds as follows: “Such communication occurs when one process names another as destination [to receive a request] and the second process names the first as source for [the request] ... [in order that providing the request] is delayed until the other process is ready [to receive the request].”
Synchronized requesting x with request r (i.e. x!r) can be implemented as follows using a 2-phase commit protocol: x.synchronize[Implements Provider ⟦provide ↦ r⟧] so that after x has received a synchronize message with parameter Implements Provider ⟦provide ↦ r⟧, x can get r from the parameter using a provide message (cf. [Knabe 1992]). Synchronized sending x a request r (i.e. x!r) can be algebraically reduced (which is a primary requirement of communication in the π-calculus [Milner 1993]) because x is provided with r without arbitration by Implements Provider ⟦provide ↦ r⟧.
Synchronized requesting (i.e. x!r) has the following significant costs in time, communication bandwidth, and robustness by comparison with unsynchronized Actor requesting (i.e. x.r):
1. The requester must wait for the receiver’s provide message in order to provide request r.
2. After receiving a synchronize message, the receiver must wait for the request r to be provided (meanwhile holding up processing of other requests).
3. Both the requester and receiver must be online concurrently for communication to take place.
Unsynchronized requesting (i.e. x.r) cannot in general be reduced using an algebraic equation as in [Milner 1993] because in general, the request must go through arbitration in order to be received. Although algebraic reductions may be elegant mathematics, synchronized requesting is not widely used in large software systems because it is slower, uses more communication bandwidth, and is less robust than asynchronous requesting (especially for IoT).
According to [Milner 1993]:
“An important task is to compare it {π-calculus based on algebraic reduction using synchronized requesting} with Hewitt's Actors; there are definite points of agreement where we have followed the intuition of Actors and also some subtle differences, such as the treatment of names {i.e., request providers}. More generally, the π-calculus is a formal calculus, while the Actors model, in spirit closer to the approach of physics, sets out to identify the laws {i.e. [Hewitt and Baker 1977] expanded into the uniquely categorical axiomatization in this article} which govern the primitive concepts of interaction.”
- smallstepforman 7y agoHi Carl. Pleasure to read your comments. I’ve tried applying Actors to my C++ projects and always hit 2 issues in Actor model: 1) the need for synchronous access. As long as a single thread is accessing each Actor sequentially, then there is no issue with locking an Actor for synchronous access (barring deadlocks). I feel dirty locking Actors, but it solves many practical problems. 2) sharing resources requires a language which understands locks, since even Pony’s reference capabilities doesn’t solve real world performance issues. Ideally, each shared resource would have a paired lock whose usage the compiler verifies. Both issues deviate from Actor model purity since they require locks, but I cannot resolve real world performance problems without them.
- ProfHewitt 7y agoThanks! Unfortunately, C++ has many issues implementing Actors because of problems with regions of mutual exclusion with holes. See the following: https://papers.ssrn.com/abstract=3418003 https://papers.ssrn.com/abstract=3418003
- DonHopkins 7y agoHi, and thank you for all your intriguing messages and thoughtful arguments! I've heard that Actors don’t have an identity, only addresses: https://medium.com/@alex_karaberov/everything-you-always-wanted-to-know-about-the-actor-model-but-were-afraid-to-ask-b6eee8722953 https://medium.com/@alex_karaberov/everything-you-always-wan... >Each actor has an address. In various implementations an address can be a direct physical address (e.g. MAC address of the NIC), email, memory address, some id and so on. Multiple actors can have the same address, and one actor can have multiple addresses. There is a many-to-many relationship here. Address is not a unique identifier of the actor. Actors don’t have an identity, only addresses. So, when we step back and look at our conceptual Actor Model, we can see and use only addresses. We can not tell whether we have one actor or multiple ones even if we have one address, because it can be a proxy for the group of actors. All we can do with an address is send it a message. Address represents capability in the Actor Model. Mapping of addresses and actors is not part of the conceptual Actor Model although it is a feature of implementations. So I was wondering if you're the same Carl E Hewitt as https://news.ycombinator.com/user?id=carlehewitt https://news.ycombinator.com/user?id=carlehewitt and as your user name professes, or if either or both of you are actors? ;) And have you ever played Santa Claus? https://www.youtube.com/watch?v=AtnBumt82_Y https://www.youtube.com/watch?v=AtnBumt82_Y