readsync: Syncing file-backed variables.
In matloff/Rdsm: Threads Environment for R

Description Usage Arguments Details Value Author(s) Examples

Actions to propagate changes to file-backed Rdsm variables across a shared file system.

1 2	readsync(varname) writesync(varname)

varname

Name of the Rdsm variable, quoted.

This feature should be considered experimental, with poor performance and portability.

Suppose we have an Rdsm variable x which is in backing store (fs = TRUE in call to mgrmakevar()), and that we on a shared file system. (These functions are not needed if all threads are on the same machine.) When one Rdsm thread writes to x, the question here is when the updated value for x is visible to other Rdsm threads.

The answer may depend on the underlying file system. The functions readsync() and writesync() force the updates across the network. Normally one would call readsync() following rdsmlock() and call writesync() just before calling rdsmunlock().

These should work on systems with "close-to-open cache coherency," as with the Network File System (NFS). On some systems, these functions should be unnecessary.

None.

Norm Matloff

library(parallel)
c2 <- makeCluster(2)
mgrinit(c2)
mgrmakevar(c2,"x",1,1,fs=TRUE)

clusterEvalQ(c2,me <- myinfo$id)
clusterEvalQ(c2,if (me==1) x[1,1] <- 3)
# force update on network
clusterEvalQ(c2,if (me==1) writesync("x"))  
clusterEvalQ(c2,if (me==2) readsync("x"))  
clusterEvalQ(c2,if (me==2) x[1,1])  # should be 3
clusterEvalQ(c2,if (me==2) x[1,1] <- 8)
clusterEvalQ(c2,if (me==2) writesync("x"))  
clusterEvalQ(c2,if (me==1) readsync("x"))  
clusterEvalQ(c2,x[1,1])  # both should yield 8