Command: Release lock back to lock pool, making it available for future LOCKNEW requests.

((PUB ┆ PRI))
  LOCKRET ( ID )

• ID is the ID (0 – 7) of the lock to return to the lock pool.

Explanation

LOCKRET is one of four lock commands (LOCKNEW, LOCKRET, LOCKSET, and LOCKCLR) used to manage resources that are user-defined and deemed mutually exclusive. LOCKRET returns a lock, by ID, back to the Hub's lock pool so that it may be reused by other cogs at a later time. For example:

LOCKRET(2)

This example returns Lock 2 back to the Hub. This doesn't prevent cogs from accessing Lock 2 afterwards, it only allows the Hub to reassign it to cogs that call LOCKNEW in the future. Applications should be written such that locks are not accessed with LOCKSET or LOCKCLR unless they are currently checked out.

See Locks for information on the typical use of locks and the LOCKxxx commands.

Note that user-defined resources are not actually locked by either the Hub or the checked-out lock. The lock feature only provides a means for objects to cooperatively lock those resources. It's up to the objects themselves to decide on, and abide by, the rules of lock use and what resource(s) will be governed by them. Additionally, the Hub does not directly assign a lock to the cog that called LOCKNEW, rather it simply marks it as being "checked out" by a cog; any other cog can "return" locks to the pool of available locks. Also, any cog can access any lock through the LOCKCLR and LOCKSET commands even if those locks were never checked out. Doing such things is generally not recommended because of the havoc it can cause with other, well-behaved objects in the application.

See LOCKNEW, LOCKCLR, and LOCKSET for more information.