Prolog threads can exchange data using dynamic predicates, database records, and other globally shared data. In addition, they can send messages to each other. If a threads needs to wait for another thread until that thread has produced some data, using only the database forces the waiting thread to poll the database continuously. Waiting for a message suspends the thread execution until the message has arrived in its message queue.
thread_get_message1?Term Examines the thread message-queue and if necessary blocks execution until a term that unifies to Term arrives in the queue. After a term from the queue has been unified unified to Term, this term is deleted from the queue and this predicate returns.
Please note that not-unifying messages remain in the queue. After the following has been executed, thread 1 has the term bgnu in its queue and continues execution using A is gnat.
See also thread_peek_message1. thread_peek_message1?Term Examines the thread message-queue and compares the queued terms with Term until one unifies or the end of the queue has been reached. In the first case the call succeeds (possibly instantiating Term. If no term from the queue unifies this call fails. thread_signal2+ThreadId, :Goal Make thread ThreadId execute Goal at the first opportunity. In the current implementation, this implies at the first pass through the Call-port. The predicate thread_signal2 itself places Goal into the signalled-thread's signal queue and returns immediately.
Signals (interrupts) do not cooperate well with the world of multi-threading, mainly because the status of mutexes cannot be guaranteed easily. At the call-port, the Prolog virtual machine holds no locks and therefore the asynchronous execution is safe.
Goal can be any valid Prolog goal, including throw1 to make the receiving thread generate an exception and trace0 to start tracing the receiving thread.