thread.pl -- High level thread primitives

This module defines simple to use predicates for running goals concurrently. Where the core multi-threaded API is targeted at communicating long-living threads, the predicates here are defined to run goals concurrently without having to deal with thread creation and maintenance explicitely.

Note that these predicates run goals concurrently and therefore these goals need to be thread-safe. As the predicates in this module also abort branches of the computation that are no longer needed, predicates that have side-effect must act properly. In a nutshell, this has the following consequences:

• Nice clean Prolog code without side-effects (but with cut) works fine.
• Side-effects are bad news. If you really need assert to store intermediate results, use the thread_local/1 declaration. This also guarantees cleanup of left-over clauses if the thread is cancelled. For other side-effects, make sure to use call_cleanup/2 to undo them should the thread be cancelled.
• Global variables are ok as they are thread-local and destroyed on thread cancellation. Note however that global variables in the calling thread are not available in the threads that are created. You have to pass the value as an argument and initialise the variable in the new thread.
• Thread-cancellation uses thread_signal/2. Using this code with long-blocking foreign predicates may result in long delays, even if another thread asks for cancellation.

author

- Jan Wielemaker

 concurrent(+N, :Goals, Options) is semidet

Run Goals in parallel using N threads. This call blocks until all work has been done. The Goals must be independent. They should not communicate using shared variables or any form of global data. All Goals must be thread-safe.

Execution succeeds if all goals have succeeded. If one goal fails or throws an exception, other workers are abandoned as soon as possible and the entire computation fails or re-throws the exception. Note that if multiple goals fail or raise an error it is not defined which error or failure is reported.

On successful completion, variable bindings are returned. Note however that threads have independent stacks and therefore the goal is copied to the worker thread and the result is copied back to the caller of concurrent/3.

Choosing the right number of threads is not always obvious. Here are some scenarios:

• If the goals are CPU intensive and normally all succeeding, typically the number of CPUs is the optimal number of threads. Less does not use all CPUs, more wastes time in context switches and also uses more memory.
• If the tasks are I/O bound the number of threads is typically higher than the number of CPUs.
• If one or more of the goals may fail or produce an error, using a higher number of threads may find this earlier.

Arguments:

N	- Number of worker-threads to create. Using 1, no threads are created. If N is larger than the number of Goals we create exactly as many threads as there are Goals.
Goals	- List of callable terms.
Options	- Passed to thread_create/3 for creating the workers. Only options changing the stack-sizes can be used. In particular, do not pass the detached or alias options.

See also

- In many cases, concurrent_maplist/2 and friends is easier to program and is tractable to program analysis.

 submit_goals(+List, +Id0, +Module, +Queue, -Vars) is det[private]

Send all jobs from List to Queue. Each goal is added to Queue as a term goal(Id, Goal, Vars). Vars is unified with a list of lists of free variables appearing in each goal.

 concur_wait(+N, +Done:queue, +VT:compound, +Cleanup, -Result, +Exitted0, -Exitted) is semidet[private]

Wait for completion, failure or error.

Arguments:

Exited

- List of thread-ids with threads that completed before all work was done.

 worker(+WorkQueue, +DoneQueue) is det[private]

Process jobs from WorkQueue and send the results to DoneQueue.

 concur_cleanup(+Result, +Workers:list, +Queues:list) is det[private]

Cleanup the concurrent workers and message queues. If Result is not true, signal all workers to make them stop prematurely. If result is true we assume all workers have been instructed to stop or have stopped themselves.

 concurrent_maplist(:Goal, +List)

 concurrent_maplist(:Goal, +List1, +List2)

 concurrent_maplist(:Goal, +List1, +List2, +List3)

Concurrent version of maplist/2. This predicate uses concurrent/3, using multiple worker threads. The number of threads is the minimum of the list length and the number of cores available. The number of cores is determined using the prolog flag cpu_count. If this flag is absent or 1 or List has less than two elements, this predicate simply calls the corresponding maplist/N version.

Note that the the overhead of this predicate is considerable and therefore Goal must be fairly expensive before one reaches a speedup.

 first_solution(-X, :Goals, +Options) is semidet

Try alternative solvers concurrently, returning the first answer. In a typical scenario, solving any of the goals in Goals is satisfactory for the application to continue. As soon as one of the tried alternatives is successful, all the others are killed and first_solution/3 succeeds.

For example, if it is unclear whether it is better to search a graph breadth-first or depth-first we can use:

search_graph(Grap, Path) :-
         first_solution(Path, [ breadth_first(Graph, Path),
                                depth_first(Graph, Path)
                              ],
                        []).

Options include thread stack-sizes passed to thread_create, as well as the options on_fail and on_error that specify what to do if a solver fails or triggers an error. By default execution of all solvers is terminated and the result is returned. Sometimes one may wish to continue. One such scenario is if one of the solvers may run out of resources or one of the solvers is known to be incomplete.

on_fail(Action)

If stop (default), terminate all threads and stop with the failure. If continue, keep waiting.

on_error(Action)

As above, re-throwing the error if an error appears.

bug

- first_solution/3 cannot deal with non-determinism. There is no obvious way to fit non-determinism into it. If multiple solutions are needed wrap the solvers in findall/3.

 thread_options(+Options, -ThreadOptions, -RestOptions) is det[private]

Split the option list over thread(-size) options and other options.

 concurrent_maplist(:Goal, +List)

 concurrent_maplist(:Goal, +List1, +List2)

 concurrent_maplist(:Goal, +List1, +List2, +List3)

Concurrent version of maplist/2. This predicate uses concurrent/3, using multiple worker threads. The number of threads is the minimum of the list length and the number of cores available. The number of cores is determined using the prolog flag cpu_count. If this flag is absent or 1 or List has less than two elements, this predicate simply calls the corresponding maplist/N version.

Note that the the overhead of this predicate is considerable and therefore Goal must be fairly expensive before one reaches a speedup.

 concurrent_maplist(:Goal, +List)

 concurrent_maplist(:Goal, +List1, +List2)

 concurrent_maplist(:Goal, +List1, +List2, +List3)

Concurrent version of maplist/2. This predicate uses concurrent/3, using multiple worker threads. The number of threads is the minimum of the list length and the number of cores available. The number of cores is determined using the prolog flag cpu_count. If this flag is absent or 1 or List has less than two elements, this predicate simply calls the corresponding maplist/N version.

Note that the the overhead of this predicate is considerable and therefore Goal must be fairly expensive before one reaches a speedup.