Description Usage Arguments Details Value Author(s) Examples
Actions to propagate changes to file-backed Rdsm variables across a shared file system.
1 2 |
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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | 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
|
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.