Locks

As wikipedia tells, a lock or a mutex is a synchronization primitive that allows one thread to obtain a resource and block others from accesing it, until is terminated and sends a signal to others to try to obtain the lock.

In our case, the lock interface will give a token to the first client requesting it, and will block or deny the token to the next ones. This until the client with the token releases it with unlock.

Every lock has a name, and the client must provide it in the operations that it will use. Two clients using the same name in several operations will apply to the same lock.

The operations are

• lock - If the lock is not taken, the first client obtains a token. If the lock is taken, the clients wait until the 'tokenized' one unlocks it
• tryLock - If the lock is not taken, the first client obtains a token. If the lock is taken, the clients revieves an empty or null string. No waiting associated.
• tryLockWithTimeOut - If the lock is not taken, the first client obtains a token. If the lock is taken, the client waits the given time. If token remains given, the clients revieves an empty or null string. You can send the time unit of the time out or assume it's milliseconds.
• lockStatus - Given a token, it will tell you the status of the token
  • ABSENT - there is no token
  • UNLOCKED - there is a unlocked lock, ungiven token
  • OWNER - you and this token are the owners of the lock
  • OTHER - other client with other token is the owner of the lock
• unLock - returns true if you provide the current token to unlock the lock and allow other clients to obaint the lock and the token, false otherwise

Only in gRPC, there is an asynLock operation, works as the lock call; but will return the response asynchronously and when the lock is unlocked (it can be in a moment before the call)

Locks will stay forever in memory if they are locked (token given) and will be removed eventually if unlocked (token not given). ( There is no problem in reusing a lock name that has been used for a removed lock. )