## 5 IO Data Management and Data Sharing
### Distributed SQL Databases with RPC
#### 5.1.1. Replicated Data Bases and Tables
The data state of a cell consists of private variables \(s\) and public variables \(S\). The private state must only be shared with the neighboring cells. Only those cells near the partition boundary (with a neighbor partition) require communication by messaging or using shared memory, as shown in Figure 9.

The CA world is partitioned into \(M\) partitions. The number of parallel processed partitions depends on the total number of cells \(N\). To benefit from parallel processing, the communication overhead must be considered carefully, which is also dependent on the communication class. Message-based communication is expensive; shared memory communication is more efficient, but it still increases the cell access time to their own state variables. To minimize communication and memory complexity, private state variables are only shared with other partitions within the neighborhood radius, using slice-shared memory arrays, and public (globally visible) state variables (the output of a cell) are merged in a compact shared memory matrix, limiting the types of these state variables to atomic data types, like integer numbers. Figure 9: The basic partitioned architecture of the CA. Each partition of the CA world is executed in a separate process. Data exchange is performed via shared memory. The case study is a simple particle random-walk simulation. The model is shown in Example 11. The full source code can be found in Appendix A. A more complex example using the PSciLab software framework can be found in [28], where longitudinal and spatial infection development is studied. The results from the simple random walk simulation can be directly transferred to the more complex infection simulation. Additionally, the simulation world was partitioned into different spatial domains (e.g., home and working area), enabling more efficient parallel and distributed processing. ```
varmodel={ rows:20,columns:20, partitions:[2,2], parameter:{P:0.3}, radius:1,neighbors:8, cell:{ private:{id:0,next:null}, shared:{place:0}, public:{color:0}, before:function(x,y){ if(this.place==0)return; this.next=this.ask(this.neighbors,'random','place',0) }, activity:function(x,y){ if(this.place==0)return; if(this.next)this.next.place=this.id; }, after:function(x,y){ if(this.next&&this.next.place==this.id){ this.place=0;//wehavewonthecompetition } } this.next=null; this.color=this.place==0?0:1 }, init:function(x,y){ this.id=1+this.model.rows*y*x; if(Math.random()<this.P)this.place=this.id; elsethis.place=0; this.next=null; this.color=this.place==0?0:1 } } } varsimu=CAP.Lib.SimuPar(model,{print:Code.print});awaitsimu.createWorker()awaitsimu.init()awaitsimu.run(100)
```
Example 11. CA random-walk model, used for the parallel simulator (here, with \(2\times 2\) partitions). The simulator processes the cells in three phases that are synchronized by three barriers: Before, Activity, After. This three-phase protocol is required to avoid race conditions, due to the concurrent modification of shared memory objects. In the first phase, each cell with _place_\(\
eq 0\) selects one neighbor cell randomly with _place_ = 0 (not occupied). In the main activity, each occupied cell allocates the _next_ place with their unique identifier number. In the third phase, the current place occupation is only removed if the occupant ID won a possible neighbor-cell competition (i.e., _next.place_ is equal to the current identifier number), otherwise, the current occupant stays in the original cell. The problem size is constant; the partitioning of the CA world in smaller parallel-processed sub-partitions should create a speeding-up of the overall simulation time (per simulation step). Experimental results are shown in Figure 10 for desktop and workstation computers and in Figure 11 for web browsers. The scaling for parallel computing is under-linear and the speeding-up saturates, mostly due to the bottleneck of the shared memory architecture of the host platform. Even on a 2 CPU/12-core workstation, the maximal speeding-up is below 6 (12 is expected).