synchronicity: Synchronicity with backing store locks
In Burke-Lauenroth-Lab/SoilWat_R_Wrapper: Simulation Framework for SOILWAT2

Access to the backing store lock is attempted until successfully obtained.

lock_init(fname_lock, id)

check_lock_content(lock)

remove_lock(lock)

unlock_access(lock)

lock_attempt(lock)

lock_access(lock, verbose = FALSE, seed = NA)

`fname_lock`	A character string. Path to locking directory.
`id`	A R object. Identifier used to test unique write access in locking directory.
`lock`	An object of class `SFSW2_lock`.
`verbose`	A logical value. If `TRUE`, then each attempt at obtaining the lock is printed.
`seed`	A seed set, `NULL`, or `NA`. `NA` will not affect the state of the RNG; `NULL` will re-initialize the RNG; and all other values are passed to `set.seed`.

An object of class SFSW2_lock.

A logical value. TRUE if lock file contains proper code of the lock.

The return value of deleting the directory associated with lock.

The updated lock object of class SFSW2_lock.

My attempts at using lock/unlock functions from flock failed because unlock appeared to not free resources. My attempts at using such functions from synchronicity failed because of segfaults with GetResourceName(m@mutexInfoAddr); additionally, synchronicity is restricted to unix systems. Instead, I use here ideas based on functions from Rdsm and Samuel.

Burke-Lauenroth-Lab/SoilWat_R_Wrapper documentation built on Aug. 14, 2020, 5:17 p.m.