1 (request) 3 Invalid (redundant) request that is, requesting a lock already granted A null LockString in the LockString with a Control Code of 1 indicates a lock request for an exclusive AsyncLock lock. A non-null LockString in the LockString with a Control Code of 1 indicates a request for a shared lock. AsyncLock An with the Control Code set to 0 indicates a request to release the lock. AsyncLock HiSLIP servers shall respond to lock requests as shown in Table 15 Lock BehaviorTable 15. Note that the state’ ‘lock described in this table is the lock state across all active HiSLIP sessions. After the Initialization and Device Clear transaction, the client shall use the MessageID = 0xfffffefe (0xffffff00-2) in the (release) message. AsyncLock Table Lock Behavior Initial Lock request Client New State State Unlocked Shared lock any client success Shared Locked  (initial Exclusive lock any client success Exclusive Locked  state) Release any client error Unlocked  Exclusive Shared Lock holder of exclusive lock error Exclusive Locked  locked other client fails after lock timeout Exclusive Locked  Exclusive lock client not holding the lock after lock timeout Exclusive Locked  holder of exclusive lock Exclusive Locked  Release holder of exclusive succeeds Unlocked  client without exclusive lock error Exclusive locked  Shared Shared lock holder of shared lock error Shared Locked  locked other client with right key succeeds Shared Locked  other client with wrong key fails after lock timeout Shared Locked  Exclusive lock holder of shared lock succeeds Both Locks  client not holding shared lock after lock timeout Shared Locked  Release holder of the shared lock when 2 or more are holding Shared Locked shared lock succeeds  the only remaining holder of the shared lock Succeeds Unlocked  client holding no error Shared Locked  Both Shared Lock holder of shared lock error Both locks  locks other client with right key succeeds Both locks  other client with wrong key fails after lock timeout Both  Exclusive lock client not holding the exclusive lock fails after timeout Both locks  client holding the exclusive lock Both  Release holder of exclusive and shared lock succeeds Shared locked  other client holding a shared lock succeeds Both Locks  client holding no locks error Both locks  HiSLIP servers shall: Go to the Unlocked state when the first connection is initialized Release all locks assigned to a client when that client connection closes
1 (request) 3 Invalid (redundant) request that is, requesting a lock already granted A null LockString in the AsyncLock LockString with a Control Code of 1 indicates a lock request for an exclusive lock. A non-null LockString in the AsyncLock LockString with a Control Code of 1 indicates a request for a shared lock. An AsyncLock with the Control Code set to 0 indicates a request to release the lock. HiSLIP servers shall respond to lock requests as shown in Table 15 Lock BehaviorTable 15. Note that the ‘lock state’ described in this table is the lock state across all active HiSLIP sessions. After the Initialization and Device Clear transaction, the client shall use the MessageID = 0xfffffefe (0xffffff00-2) in the AsyncLock (release) message. Table Lock Behavior Initial State Lock request Client New State Unlocked (initial state) Shared lock any client  success Shared Locked Exclusive lock any client  success Exclusive Locked Release any client  error Unlocked Exclusive locked Shared Lock holder of exclusive lock  error Exclusive Locked other client  fails after lock timeout Exclusive Locked Exclusive lock client not holding the lock  after lock timeout Exclusive Locked holder of exclusive lock  Exclusive Locked Release holder of exclusive  succeeds Unlocked client without exclusive lock  error Exclusive locked Shared locked Shared lock holder of shared lock  error Shared Locked other client with right key  succeeds Shared Locked other client with wrong key  fails after lock timeout Shared Locked Exclusive lock holder of shared lock  succeeds Both Locks client not holding shared lock  after lock timeout Shared Locked Release holder of the shared lock when 2 or more are holding shared lock  succeeds Shared Locked the only remaining holder of the shared lock  Succeeds Unlocked client holding no  error Shared Locked Both locks Shared Lock holder of shared lock  error Both locks other client with right key  succeeds Both locks other client with wrong key  fails after lock timeout Both Exclusive lock client not holding the exclusive lock  fails after timeout Both locks client holding the exclusive lock  Both Release holder of exclusive and shared lock  succeeds Shared locked other client holding a shared lock  succeeds Both Locks client holding no locks  error Both locks HiSLIP servers shall: Go to the Unlocked state when the first connection is initialized Release all locks assigned to a client when that client connection closes