Propeller Manual

2: Spin Language Reference – LOCKRET
Propeller Manual v1.1 · Page 125
LOCKRET
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 (T LOCKNEW, LOCKRETT, LOCKSET, and T 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 About Locks, page 122, and Suggested Rules for Locks, page 123 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, page 122; LOCKCLR, page 120; and LOCKSET, page126 for more information.