OEP

150

Title

CREW support

Summary

Allow variables to be protected by CREW locks.

Owner

Peter Welch

Status

Proposed

Date-Proposed

2006-03-24

Keywords

language crew shared

Concurrent-Read-Exclusive-Write locks may be used to protect a resource that may be read by many processes concurrently but only written to by one. A userspace implementation of CREW locks is presently included in the KRoC distribution, but it would be much more convenient to make it available as a basic type in the language, with operations to claim the lock for reading and writing:

CREW INT speed:
PAR
  SEQ
    ...
    CLAIM WRITE speed
      speed := new.value
    ...
  SEQ
    ...
    CLAIM READ speed
      local.var := speed
    ...

It would also be useful to have CREW locks available that are not tied to a particular variable, which can be used to protect larger "resources" such as process systems. These could be declared as just:

CREW lock:

(For consistency, it may also be worth considering whether tying BARRIERs to variables would be useful.)

For small types (such as the INT above) where atomic operations are available and where the code inside the CLAIMs is trivial, the compiler could avoid generating the code to perform the CREW operation entirely, using atomic operations to update and read the protected variable. (On uniprocessor KRoC, it would not even be necessary to use atomic operations.)

CREW locks may have other uses; one example application had a number of worker processes performing transactions, and an audit process which periodically needed to stop all the workers in a state where they were not engaged in a transaction. This was achieved using a CREW lock, shared by all the workers and the auditor, where a read lock was obtained to do a transaction and a write lock to do an audit; when the write lock was obtained, the auditor could be guaranteed that none of the workers were in a transaction.

OEP/150 (last edited 2007-09-27 01:23:26 by ats1)