The following describes how the categories of requests are handled, in each of the lock states of a service. Note that although the description refers to queues and other implied implementation characteristics, this is only for convenience; no particular implementation techniques are required.
Service state: UNLOCKED
Non-deferred requests are processed on arrival.
Deferred requests are placed in the deferred queue and processed FIFO.
When a WFPLock request arrives:
The lock request is placed in the lock queue.
The service state changes to LOCK_PENDING.
Service state: LOCK_PENDING
All requests in the deferred queue that arrived before the pending lock request are processed FIFO; after all are processed, the the lock queue is processed. Note that depending on the nature of the service/device, lock requests may be granted FIFO or in some other order, e.g., when an operator takes an action such as pressing a station button.
When a lock request has been granted:
The service state changes to LOCKED.
Any other pending lock requests from the same “owner” are also granted. (The owner is the same if it comes from the same workstation and has the same application and service handles.)
Service state: LOCKED
Arriving requests (except lock requests) are handled as follows:
Non-deferred requests are processed on arrival.
Deferred requests that are notWFPExecute requests are placed in the deferred queue.
WFPExecute requests from the owner of the lock are placed in the deferred queue.
WFPExecute requests that are not from the owner of the lock are rejected (with error code WFS_ERR_LOCKED).
WFPUnlock and WFPClose requests from the owner of the lock are placed in the deferred queue. (Note that a close request to a locked service is treated as an unlock followed by a close.)
WFPUnlock and WFPClose requests that are not from the owner of the lock are treated as non-deferred requests, i.e., processed on arrival.
The deferred queue is processed FIFO.
When a WFPLock request arrives:
If it is from the owner of the lock, it is granted.
If it is not from the owner of the lock, it is placed in the lock queue.
When a WFPUnlock or WFPClose request is processed from the deferred queue, or the connection between the service and the owner of the lock is lost:
If the lock queue is not empty, the service state changes to LOCK_PENDING.
If the lock queue is empty, the service state changes to UNLOCKED.
Note that most requests include a timeout parameter which must be managed appropriately, i.e., when the specified time expires, the request is rejected with the error code WFS_ERR_TIMEOUT. The timeout parameter is particularly important with the WFSLock request, since it allows applications to set a maximum time to wait for a lock to be granted, to allow prevention of deadlock situations when requesting locks of multiple devices.