Apart from creating and destroying a RanQue, you can put an item into it, attempt to extract an item, and notify that the last item you extracted has been dealt with. The last two are long-running operations that may block, hence they have a counter interface.
Each physical processor has to call before multithreading begins. Returns a RanQue ID to be used as a handle later.
Destroys a RanQue and releases bookkeeping space, usually called after the main multithreading scheduler has exited.
Takes as input a global pointer to the element to be put into a RanQue, and enqueues it to the local processor of a random PE. Integer k is a key value on which local pools of elements are heaped. The random policy can be modified, like in Chih-Po's task queue. This is not a long-running operation. By the time that RanQue_put returns, the calling processor can assume the put will take effect within finite time. Thus, no counters are needed.
Attempt to obtain the best (minimum value of k) item from the local pool. The invoking thread passes its continuation using the standard counter protocol. When the continuation is ready, one of two things will have happened: either the thread will get a RANQUE_TERM return status, indicating that the RanQue has terminated, or get a handle to an item.
The RanQue needs to detect termination. As in Chih-Po's task queue, this is tricky because a distributed consensus has to be reached. For return status see the header files. Returns a success status within finite time of termination, and never returns success unless and until termination occurs. To enable this, the application has to extract an item (tasks, most usually), solve the task, generate children, and let RanQue know it is done with the last obtained task. This is accomplished by calling RanQue_done.