Currently, DataSpaces offers two lock types: Generic and Custom.
The generic lock does not guarantee synchronization. The writer is allowed to progress at its own pace. Then, the reader can obtain a read-lock whenever it asks for it and try to read data. However, as mentioned above, if there is invalid data, DataSpaces will return potentially just garbage or fail, and the simulation will keep progressing (in case one) or fail (in case two).
The custom lock was meant to enforce a certain type of synchronization among the tasks, but it has a number of limitations. For example, there can only be one writer. And an application can only have one role (either reader or writer), because of the way this lock is implemented.
The idea is not to modify the existing lock type 2 code, but instead, to add a lock type 3 that enforces synchronization, but still allows a process to have multiple roles (i.e., writer and reader) and to allow for more than one application to write. Our goal is to have it behave in the following way: This lock type will strictly enforce a uniform scheme, where if one application writes and two read, then that is the expected order. This lock type eliminates the need for user-based synchronization, but the consumer blocks (holds the lock) until the expected producer puts data in the space. Likewise, the producer blocks until the consumer gets data from the space.
Further, DataSpaces team should investigate other types of consistency schemes and locks that make sense for the project. This priority is not high.
copied from tertius issues num. 40
Currently, DataSpaces offers two lock types: Generic and Custom.
The generic lock does not guarantee synchronization. The writer is allowed to progress at its own pace. Then, the reader can obtain a read-lock whenever it asks for it and try to read data. However, as mentioned above, if there is invalid data, DataSpaces will return potentially just garbage or fail, and the simulation will keep progressing (in case one) or fail (in case two).
The custom lock was meant to enforce a certain type of synchronization among the tasks, but it has a number of limitations. For example, there can only be one writer. And an application can only have one role (either reader or writer), because of the way this lock is implemented.
The idea is not to modify the existing lock type 2 code, but instead, to add a lock type 3 that enforces synchronization, but still allows a process to have multiple roles (i.e., writer and reader) and to allow for more than one application to write. Our goal is to have it behave in the following way: This lock type will strictly enforce a uniform scheme, where if one application writes and two read, then that is the expected order. This lock type eliminates the need for user-based synchronization, but the consumer blocks (holds the lock) until the expected producer puts data in the space. Likewise, the producer blocks until the consumer gets data from the space.
Further, DataSpaces team should investigate other types of consistency schemes and locks that make sense for the project. This priority is not high.