Prolog threads can exchange data using dynamic predicates, database records, and other globally shared data. These provide no suitable means to wait for data or a condition as they can only be checked in an expensive polling loop. Message queues provide a means for threads to wait for data or conditions without using the CPU.
Each thread has a message-queue attached to it that is identified by the thread. Additional queues are created using message_queue_create/1.
If more than one thread is waiting for messages on the given queue and at least one of these is waiting with a partially instantiated Term, the waiting threads are all sent a wake-up signal, starting a rush for the available messages in the queue. This behaviour can seriously harm performance with many threads waiting on the same queue as all-but-the-winner perform a useless scan of the queue. If there is only one waiting thread or all waiting threads wait with an unbound variable an arbitrary thread is restarted to scan the queue.84See the documentation for the POSIX thread functions pthread_cond_signal() v.s. pthread_cond_broadcast() for background information.
Please note that not-unifying messages remain in the queue. After the
following has been executed, thread 1 has the term b(gnu)
in its queue and continues execution using A = gnat.
<thread 1> thread_get_message(a(A)), <thread 2> thread_send_message(Thread_1, b(gnu)), thread_send_message(Thread_1, a(gnat)),
See also thread_peek_message/1.
message_queue_create(Alias), but according to the
ISO draft on Prolog threads.