All internal Prolog operations are thread-safe. This implies two Prolog threads can operate on the same dynamic predicate without corrupting the consistency of the predicate. This section deals with user-level mutexes (called monitors in ADA or critical-sections by Microsoft). A mutex is a MUTual EXclusive device, which implies at most one thread can hold a mutex.
Mutexes are used to realise related updates to the Prolog database. With `related', we refer to the situation where a `transaction' implies two or more changes to the Prolog database. For example, we have a predicate address/2 , representing the address of a person and we want to change the address by retracting the old and asserting the new address. Between these two operations the database is invalid: this person has either no address or two addresses, depending on the assert/retract order.
Here is how to realise a correct update:
:- initialization mutex_create(addressbook). change_address(Id, Address) :- mutex_lock(addressbook), retractall(address(Id, _)), asserta(address(Id, Address)), mutex_unlock(addressbook).
mutex_create(X, [alias(name)])is prefered over the equivalent
Although described in the thread-section, this predicate is also available in the single-threaded version, where it behaves simply as once/1.
If MutexId is an atom, and there is no current mutex with that name, the mutex is created automatically using mutex_create/1. This implies named mutexes need not be declared explicitly.
Please note that locking and unlocking mutexes should be paired carefully. Especially make sure to unlock mutexes even if the protected code fails or raises an exception. For most common cases use with_mutex/2, which provides a safer way for handling Prolog-level mutexes. The predicate call_cleanup/[2-3] is another way to guarantee that the mutex is unlocked while retaining non-determinism.
permission_errorexception is raised.
unlockedif the mutex is currently not locked or
locked(Owner, Count)if mutex is locked Count times by threads Owner. Note that, unless Owner is the calling thread, the locked status can change at any time. There is no useful application of this property, except for diagnostic purposes.bugAs Owner and Count are fetched separately from the mutex, the values may be inconsistent.