Documentation for method
lock assembled from the following types:
method lock(Lock::Async: --> Promise)
Acquires the lock, does not wait to acquire the lock. Returns a Promise that will be kept whenever the lock is acquired.
my = Lock::Async.new;.lock;
method lock(IO::Handle: Bool : = False, Bool : = False --> True)
Places an advisory lock on the filehandle. If
X::IO::Lock if lock could not be obtained, otherwise will block until the lock can be placed. If
True will place a shared (read) lock, otherwise will place an exclusive (write) lock. On success, returns
True; fails with
X::IO::Lock if lock cannot be placed (e.g. when trying to place a shared lock on a filehandle opened in write mode or trying to place an exclusive lock on a filehandle opened in read mode).
# One program writes, the other reads, and thanks to locks either# will wait for the other to finish before proceeding to read/write# Writergiven "foo".IO.open(:w)# Readergiven "foo".IO.open
method lock(IO::CatHandle: Bool : = False, Bool : = False --> True)
Acquires the lock. If it is currently not available, waits for it.
my = Lock.new;.lock;
This construct provides a low-level, OS-backed lock (on most platforms, it is a pthreads mutex, for example). The lock is reentrant, meaning that if you acquire it while already holding it then it just bumps a recursion count. Trying to acquire the lock when something else is holding it will really block a thread. If you block a thread pool thread with this construct, it won't be able to work on anything else in the meantime. Further, an await while holding a lock will not function in a non-blocking manner (as a threadpool await normally would in 6.d).
For that reason, it's better to use
protect instead of an explicit lock/unlock. That makes sure that the lock is always released. If you forget to unlock then you'll "lose" the lock and nothing will ever be able to acquire it again, probably resulting in the program deadlocking. If you really want to do the unlock yourself, the safest way is in a