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).