The chapter discusses safe usage of non-local variables, that is variables accessible by different components or threads with global variables as a particular case.

Annotations: SYNTAX: **commop(send)** (1) **commop(receive)** (2) annotation (1) marks SEND communication event. annotation (2) marks RECEIVE communication event. Specializations: SYNTAX: **commDirect** **commGuarded** Communication reasoning able to assign following specializations: commDirect — specialization is expected to provide direct access to raw variable's content. commGaurded — specialization is expected to do internal consistency checks at run time.

One of the major concepts that support writing of safe programs is a notion of immutability. Immutability tremendously simplifies many kinds of analyses; using immutable structures is a practical way to write multithreaded applications and has many other benefits beyond that. However in its most basic form it comes with a price of disastrous, in many cases, memory overhead, since property of immutability stipulates for each change of variable to make an independent copy of it occupying different memory region. Unwise using of immutable structures lead to the situation such that CPU is mostly occupied with unnecessary variables copying to and fro as well as with extensive garbage collection, irrelevant of actual algorithm's complexity at hand. Thus it is one of the central highlights of proper programming language design to provide techniques to overcome the shortcomings by relaxing immutability requirements keeping nevertheless safety benefits. There are many ways to approach the problem, and one such technique, namely communication model is discussed next.

Communication model is a way to capture and express what's going on with variables in a program as well as to define rules that describe valid operations over variables. Within the framework writing value to a variable is viewed as sending, and conversely reading variable's value is viewed as receiving. Variables that are accessed from different components or threads are referred to as non-local variables. This chapter is focused on a on-local variables, global variables particularly, since exactly for them it's hard to manually check exhaustively where and how they are used in order to catch any errors. It is natural to view them as the means of interaction between different parts of a program, in other words, interaction between sender and receiver, where sender and receiver are different components. The same terms comprise rules that express valid ways of interacting. The abstraction is named communication model due to similarity with the network communication. Reasoning based on working with a communication path, i.e chain of communication events(e.g. sending/receiving) occurred during program execution. Let's consider small example: a = init():: int; commop(send). //(1) b = a + 1 :: int; commop(receive). //(2) It shows computing of variable b. Variable b depends on a so a is calculated first. Variables a, b are annotated with comm(send) and comm(receive), denoting sending and receiving events, respectively. Communication path in this case is an ordered list {<begin>, SEND, RECEIVE, <end>} where <begin>, <end> — are special events that denote first and last events in the path, respectively. The gist of using communication model is to ensure that every sent value is properly received. It relies on the compiler to gather all possible communication paths in the program as an input for processing. There are two supported modes of reasoning: Validation. In this mode all communication paths are checked against communication rules to confirm that the program is valid. Otherwise compilation error is raised. Planning. In this mode reasoning assigns proper implementation for variables in efforts to ensure validity.

To perform validation, every communication path is checked against number of communication rules that express which communication path are valid. Default behaviour expressed by "every sent value being properly received" produce next possible cases: Valid. Path that consists of pairs of events {SEND, RECEIVE} are valid meaning that each sent value is properly received. Undefined and expired value. Paths that have parts {<begin>, RECEIVE} or {RECEIVE, RECEIVE} are invalid meaning possibly undefined value is received in the first case or duplication i.e. expired value is used in the second's one. Lost value. Paths that have parts {SEND, SEND} or {SEND, <end>} indicate possibly lost change since consequent sender replaces value in the former case and sent value is not used at all in the latter case. Traditional immutability validation is based on the idea that once valid value is valid as long it is unmodified. In this regards communication model can be viewed as an extension and more expressive tool since it also captures value expiration after it was used as well as value loss, if it was not used at all.

Reasoning in the communication model aside of performing validation, also assigns appropriate specialization for sending and receiving operations, as appropriate. At the moment there are two specializations the operations are expected to support: Direct. Direct specialization commDirect is expected to provide direct access to variable's value. This specialization is assigned in case of fully statically validated communication path. Guarded. In case if there are possible communication path inconsistencies that can not be completely ruled out at compile time, checking logic should be embedded into compiled code. Specialization commGaurded is expected to hold variable state and check usage consistency.

Reasoning implements algorithm that is bounded by the maximal path length it can process. The parameter is called planning horizon. Any variable that it can not check due to exceedingly large path's length is assigned default implementation commGaurded that performs necessary checks during runtime. Thus the parameter regulates trade off between static analysis extensiveness and runtime checks overhead.

name="tests/effects-communication.cpp: Doc_DirImpl", lines=15 import raw("scripts/dfa/propagation.lp"). import raw("scripts/dfa/polymorphism.lp"). import raw("scripts/effects-communication/communication.lp"). import raw("scripts/effects-communication/config.lp"). CommDirect = type { value:: int }. guard:: commDirect { init = function::CommDirect { {value = 0} } read = function(vault1:: CommDirect):: int { (vault1:: *;commop(receive))["value"] } write = function(vault2:: CommDirect, valueNew:: int)::CommDirect { (vault2:: *; dfa_pseudo(vault2)) + {value = valueNew}:: int; commop(send); dfa_uppy(vault2) } } main = function::int; entry { x1 = init()::*; dfa_polym(ret). x2 = write(x1, 1)::*; dfa_polym(arg). val = read(x2)::int; dfa_polym(arg). val } In this example, basic workflow is presented in main — the function write(x1, 1) is invoked following by invocation of read(x2). Functions write() and read() are annotated with commop(send) and commop(receive) respectively in order to enable communication reasoning. Analyzer gathers and validates observed communication path and since there is no ambiguity, it's possible to assign specialization CommDirect allowing direct access to the variables avoiding any additional overhead. Note, there are no any other specializations defined and if reasoning was not enable to conclude that it is the case the compilation error would be raised.

name="tests/effects-communication.cpp: Doc_GuardedImpl", lines=15 import raw ("scripts/effects-communication/communication.lp"). import raw ("scripts/dfa/propagation.lp"). import raw ("scripts/dfa/polymorphism.lp"). import raw ("scripts/effects-communication/config.lp"). CommState = type variant{Invalid, Valid, Outdated}. CommDirect = type { value:: int }. CommGuarded = type { value:: int, state:: CommState }. guard:: commDirect { init=function::CommDirect{ {value = 0} } read= function(vault1:: CommDirect):: int{ (vault1::CommDirect; commop(receive))["value"] } write= function(vault2:: CommDirect, valueNew1:: int)::CommDirect{ (vault2::CommDirect;dfa_pseudo(vault2)) + {value = valueNew1}:: int; commop(send); dfa_uppy(vault2) } } errorRead = function:: int { -1 } errorWrite = function:: CommGuarded{ { value = -1, state = Invalid() } } guard:: commGuarded{ init=function::CommGuarded{ { value = 0, state = Invalid() } } read=function(vault3:: CommGuarded):: int { switch variant (vault3["state"]->whatever::CommState;commop(receive)):: int case (Invalid) { errorRead() } case (Outdated) { errorRead() } case (Valid) { vault3["value"] } } write=function(vault4:: CommGuarded, valueNew2:: int)::CommGuarded{ switch variant (vault4["state"]->whatever::CommState;commop(send); dfa_pseudo(vault4))::int case (Invalid) { {value = valueNew2, state = Valid()}:: CommGuarded; dfa_uppy(vault4) } case (Outdated) { {value = valueNew2, state = Valid()}:: CommGuarded; dfa_uppy(vault4) } case (Valid) { errorWrite():: CommGuarded; dfa_uppy(vault4) } } } main=function(cmd:: num)::int; entry { x1 = init():: *; dfa_polym(ret). x2 = write(x1, 1)::*; dfa_polym(arg). x3 = if (cmd > 0)::int { y = read(x2):: int; dfa_polym(arg). y } else { z = write(x2, 2)::*; dfa_polym(arg). a = read(z):: int; dfa_polym(arg). a }. x3 } Here example of slightly more complicated workflow. Function main contains branching that depends on argument known at run time only. Analyzer is presented with two possible communication paths and one of them(false branch) leads to a possibly lost value for it contains two consequent SEND events. In this situation the analyzer unable to statically validate correctness and assigns specialization commGuarded to embed checking logic into compiled code as an intermediary layer between variable's content and client's code. Implementation commGuarded along with a variable access also tracks the variable status and returns error if the value is inconsistent.