next up previous contents index
Next: 3.2.4.1 Protected and Non-Protected Up: 3.2 Examples of Calling Previous: 3.2.3 Managing Multiple XSB   Contents   Index


3.2.4 Calling Multiple XSB Threads using Multiple C Threads

Figure 3.4 shows how two XSB threads can be created, can receive different queries and can interleave their backtracking and answer return. Although Figure 3.4 demonstrated only backtracking through simple predicates, the mechanism employed works for complicated examples using tabling, dynamic code, and other features. All this provides a sophisticated interface, but it is not ``fully'' multi-threaded in the following sense. When a C thread $T$ causes XSB to execute a command or query the thread must wait until the calling function returns before proceeding. In certain applications it may be useful, for example, for $T$ to create a C thread $T_{new}$ which runs asynchronously from $T$, executing the XSB command or query and then exiting. Alternately, an application may want to have a pool of C threads that can interact with a pool of XSB threads.

XSB's C API has been designed to support these features. Figure 3.5 shows fragments of Figure 3.4 rewritten so that the routines to print out the answers to the queries p(X,Y,Z) and r(X,Y,Z) can be called from C threads specially designed for this purpose. More specifically, the routine query_ps() calls p_th to query p(X,Y,Z) and backtrack through its answers - its use of a single void * argument and a void * return reflect the requirements of functions that are to be called using pthread_create().

We note several points about this example. First the XSB API is a low-level API that can be used to build application specific interfaces, and some experience with pthread programming is useful if multiple XSB threads are called from multiple C threads. For instance, one issue is fairness. When called from the C API each XSB thread $X_T$ makes use of mutexes to ensure that it answers only one query or command at a time. If multiple C threads are are waiting for $X_T$ to respond to requests or queries, there is no guarantee that the requests will be processed in any sort of order, or even that a request will eventually be handled (In order to ensure this, the calling program would have to use a queue or some other scheduling mechanism to send requests to the XSB thread). In addition, it is important to note that, the main XSB thread should only be called from the C thread that initialized XSB.. This restriction is due to the current design of synchronizing an XSB thread with calling threads, and may be lifted in the future.

Figure 3.5: Manipulating Multiple XSB Threads Using Multiple C Threads
\begin{figure}\begin{small}
\begin{verbatim}.....void *query_ps(void * arg) ...
... xsb_kill_thread(r_th);
xsb_close();
}\end{verbatim}
\end{small}
\end{figure}



Subsections
next up previous contents index
Next: 3.2.4.1 Protected and Non-Protected Up: 3.2 Examples of Calling Previous: 3.2.3 Managing Multiple XSB   Contents   Index
Terrance Swift 2007-10-06