... | ... | @@ -49,4 +49,25 @@ I don't have any hands-on with operators, but for what it's worth: |
|
|
* We should also plan on future operators that use resources from multiple/different modeling kernels at the same time and, by inference, work with multiple sessions concurrently.
|
|
|
* As more/future operators will be carried out remotely using REMUS or cumulus, we should plan on separating the operator template into separate functional and platform/endpoint specifications.
|
|
|
|
|
|
# Comments 20-Jul-2016 (robert)
|
|
|
|
|
|
The proposed Operator's state of not ready to run I would propose to be removed since it would require you to evaluate all the required lock requests and than return a true / false. But by the time that request has completed the locks could be removed and so you have to re-issue the request. This basically boils down to an atomic read/write issue.
|
|
|
|
|
|
instead you should have the following:
|
|
|
* Queued
|
|
|
* Running
|
|
|
* Completed ( Sub state of Valid / Error )
|
|
|
|
|
|
Now when you submit a request to do an operator you either explicitly run the operator if none of the resources are locked, or add it to the queue. The challenge than becomes how to handle the use-case of locked resource being modified / deleted while you are queued. My initial thought is that when you are removed from the queue, we re-validate the requirements and move to an Error state if any of the resources have been deleted.
|
|
|
|
|
|
The "lock" on resources should follow the classic multi consumer - single writer design. The challenge in any lock design is how to handle atomicity of the resource when you have multiple readers and something overwriting the data. Consider launch multiple async tasks that only require read locks, than halfway
|
|
|
through execution a write lock to that resource is requested by another task. You need to stall the write task while all the read tasks are completed, and if by default all locks are write, you cause all your async tasks to become heavily threaded serial tasks.
|
|
|
|
|
|
For this reasons, operators should express **what** lock types per resource they require, and than have a separate system to acquire and release locks inside subsections of the operator. Additional we should seriously consider that our lock types be:
|
|
|
- Read
|
|
|
- Modify
|
|
|
- Add
|
|
|
|
|
|
Consider a meshing operation. It requires a **Read** lock on the model resource, and an **Add** lock on the mesh resource. We don't want to force a **Modify** lock on the mesh resource, since we aren't going to touch any existing items inside the mesh resource, but we do want some ```atomicity``` with other operations that are iterating all the ```Collections``` inside the mesh resource.
|
|
|
|
|
|
|