3 ms·
Synchronized requesting in Communicating Sequential Processes (CSP) [Hoare 1978] proceeds as follows: “Such communication occurs when one process names anoth
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 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).
- tempguy9999 7y agoI suppose the key to this is in the last line - you're implying something that doesn't wait is better. That'd be actors; your creation, yes? :) But out of interest, the syncing that you apparently dislike but which actors sidestep by having a receiving queue, said syncing allows for messages to be processed when the receiver is ready (obviously). That's a time overhead. If actors have unbounded queues then there's a memory overhead (and one which may grow infinitely on a finite machine if someone isn't processing their messages fast enough). How do actors handle that? If I'm talking rubbish some reading matter is welcome.
- ProfHewitt 7y agoActually, the point is that being faster is better. Ideally, a message sent to an Actor is never stored in persistent memory. A runtime system should never accept a unbounded backlog of communications for an Actor. Instead worst case, it should generate exceptions for further requests. Here are references that you requested: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3418003 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3418003 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3459566 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3459566
- tempguy9999 7y agoMuch obliged, thank you.
- AdieuToLogic 7y agoA good article on the Actor model can be found here[0]. > If actors have unbounded queues then there's a memory overhead (and one which may grow infinitely on a finite machine if someone isn't processing their messages fast enough). Depending on the Actor implementation one employs, this concern can be mitigated. For example, Akka[1] provides BoundedMessageQueueSemantics[2] which can be used to provide hard limits. 0 - https://en.wikipedia.org/wiki/History_of_the_Actor_model https://en.wikipedia.org/wiki/History_of_the_Actor_model 1 - https://doc.akka.io/docs/akka/current/typed/index.html https://doc.akka.io/docs/akka/current/typed/index.html 2 - https://doc.akka.io/docs/akka/current/mailboxes.html#requiring-a-message-queue-type-for-an-actor https://doc.akka.io/docs/akka/current/mailboxes.html#requiri...