## Locking Commands

Most locking commands work with the environment handle. However, when a user gets a lock we create a new lock handle that they then use with in a similar manner to all the other handles to release the lock. We present the general locking functions first, and then those that manipulate locks.

> <env> lock_detect [-lock_conflict] [default|oldest|youngest|random]

This command runs the deadlock detector. It directly translates to the lock_detect DB call. It returns either a 0 (for success), a DB error message or it throws a Tcl error with a system message. The first argument sets the policy for deadlock as follows:

- default selects the DB_LOCK_DEFAULT policy for default detection (default if not specified)
- oldest selects DB_LOCK_OLDEST to abort the oldest locker on a deadlock
- random selects DB_LOCK_RANDOM to abort a random locker on a deadlock
- youngest selects DB_LOCK_YOUNGEST to abort the youngest locker on a deadlock

The second argument, -lock_conflict, selects the DB_LOCK_CONFLICT flag to only run the detector if a lock conflict has occurred since the last time the detector was run.

> <env> lock_stat

This command returns a list of name/value pairs where the names correspond to the C-structure field names of DB_LOCK_STAT and the values are the data returned. This command is a direct translation of the lock_stat DB call.

> <env> lock_id

This command returns a unique locker ID value. It directly translates to the lock_id DB call.

> <env> lock_get [-nowait]lockmode locker obj

This command gets a lock. It will invoke the lock_get function. After it successfully gets a handle to a lock, we bind it to a new Tcl command of the form $env.lockX, where X is an integer starting at 0 (e.g. $env.lock0, $env.lock1, etc). We use the Tcl_CreateObjCommand() to create the top level locking command function. It is through this handle that the user can release the lock. Internally, the handle we get back from DB will be stored as the ClientData portion of the new command set so that future locking calls will have that handle readily available.

The arguments are:

- locker specifies the locker ID returned from the lock_id command
- obj specifies an object to lock
- the lock mode is specified as one of the following:

- ng specifies DB_LOCK_NG for not granted (always 0)
- read specifies DB_LOCK_READ for a read (shared) lock
- write specifies DB_LOCK_WRITE for an exclusive write lock
- iwrite specifies DB_LOCK_IWRITE for intent for exclusive write lock
- iread specifies DB_LOCK_IREAD for intent for shared read lock
- iwr specifies DB_LOCK_IWR for intent for eread and write lock

- -nowait selects the DB_LOCK_NOWAIT to indicate that we do not want to wait on the lock

> <lock> put

This command releases the lock referenced by the command. It is a direct translation of the lock_put function. It returns either a 0 (for success), a DB error message or it throws a Tcl error with a system message. Additionally, since the handle is no longer valid, we will call Tcl_DeleteCommand() so that further uses of the handle will be dealt with properly by Tcl itself.

> <env> lock_vec [-nowait] locker {get|put|put_all|put_obj [obj] [lockmode] [lock]} ...

This command performs a series of lock calls. It is a direct translation of the lock_vec function. This command will return a list of the return values from each operation specified in the argument list. For the 'put' operations the entry in the return value list is either a 0 (for success) or an error. For the 'get' operation, the entry is the lock widget handle, $env.lockN (as described above in <env> lock_get) or an error. If an error occurs, the return list will contain the return values for all the successful operations up the erroneous one and the error code for that operation. Subsequent operations will be ignored.

As for the other operations, if we are doing a 'get' we will create the commands and if we are doing a 'put' we will have to delete the commands. Additionally, we will have to do this after the call to the DB lock_vec and iterate over the results, creating and/or deleting Tcl commands. It is possible that we may return a lock widget from a get operation that is considered invalid, if, for instance, there was a put_all operation performed later in the vector of operations. The arguments are:

- locker specifies the locker ID returned from the lock_id command
- -nowait selects the DB_LOCK_NOWAIT to indicate that we do not want to wait on the lock
- the lock vectors are tuple consisting of {an operation, lock object, lock mode, lock handle} where what is required is based on the operation desired:

- get specifes DB_LOCK_GET to get a lock. Requires a tuple {get obj mode} where mode is:

- ng specifies DB_LOCK_NG for not granted (always 0)
- read specifies DB_LOCK_READ for a read (shared) lock
- write specifies DB_LOCK_WRITE for an exclusive write lock
- iwrite specifies DB_LOCK_IWRITE for intent for exclusive write lock
- iread specifies DB_LOCK_IREAD for intent for shared read lock
- iwr specifies DB_LOCK_IWR for intent for eread and write lock

- put specifies DB_LOCK_PUT to release a lock. Requires a tuple {put lock}
- put_all specifies DB_LOCK_PUT_ALL to release all locks held by locker. Requires a tuple {put_all}
- put_obj specifies DB_LOCK_PUT_OBJ to release all locks held by locker associated with the given obj. Requires a tuple {put_obj obj}