<HTML> <HEAD> <!-- Created by texi2html 1.56k + clip patches and <A href="http://www.clip.dia.fi.upm.es/Software">lpdoc</A> from ciao.texi on 28 January 2007 --> <LINK rel="stylesheet" href="ciao.css" type="text/css"> <TITLE>The Ciao Prolog System - Low-level concurrency/multithreading primitives</TITLE> </HEAD> <BODY> Go to the <A HREF="ciao_1.html">first</A>, <A HREF="ciao_86.html">previous</A>, <A HREF="ciao_88.html">next</A>, <A HREF="ciao_241.html">last</A> section, <A HREF="ciao_toc.html">table of contents</A>. <P><HR><P> <H1><A NAME="SEC368" HREF="ciao_toc.html#TOC368">Low-level concurrency/multithreading primitives</A></H1> <P> <A NAME="IDX4736"></A> <P> <STRONG>Author(s):</STRONG> Manuel Carro. <P> <STRONG>Version:</STRONG> 1.10#7 (2006/4/26, 19:22:13 CEST) <P> <STRONG>Version of last change:</STRONG> 1.7#138 (2001/11/8, 19:50:32 CET) <P> This module provides basic mechanisms for using concurrency and implementing multi-goal applications. <A NAME="IDX4737"></A> <A NAME="IDX4738"></A> It provides a means for arbitrary goals to be specified to be run in a separate stack set; in that case, they are assigned a goal identifier with which further accesses (e.g., asking for more solutions) to the goal can be made. Additionally, in some architectures, these goals can be assigned an O.S. thread, separate from the one which made the initial call, thus providing concurrency and, in multiprocessors, parallelism capabilities. <P> As for now, the memory space of the threads (c.f., stack sets) is separate in the sense that goals are copied to the new stack set, and bindings of variables are not seen among stack sets which allows forward and backward execution to proceed independently in each stack set, at the cost of the initial goal copy. However, the program space (including, specially, the <A NAME="IDX4739"></A> concurrent predicates) are shared and seen by all the goals and threads, and should be used as the primary means of communication and synchronization. Higer level libraries can be built using these basic blocks. <P> Additionally, a small set of lock primitives are provided. Locks are associated with atom names. Whereas the concurrent database facilities are enough to implement locks, semaphores, messages, etc., the predicates implementing atom-based locks are faster than the ones accessing the concurrent database (but they are less powerful). <UL> <LI><A HREF="ciao_87.html#SEC369">Usage and interface (concurrency)</A> <LI><A HREF="ciao_87.html#SEC370">Documentation on exports (concurrency)</A> <LI><A HREF="ciao_87.html#SEC371">Known bugs and planned improvements (concurrency)</A> </UL> <H2><A NAME="SEC369" HREF="ciao_toc.html#TOC369">Usage and interface (<CODE>concurrency</CODE>)</A></H2> <div class="cartouche"> <UL> <LI><STRONG>Library usage:</STRONG> <CODE>:- use_module(library(concurrency)).</CODE> <LI><STRONG>Exports:</STRONG> <UL> <LI><EM>Predicates:</EM> <A NAME="IDX4740"></A> <CODE>eng_call/4</CODE>, <A NAME="IDX4741"></A> <CODE>eng_call/3</CODE>, <A NAME="IDX4742"></A> <CODE>eng_backtrack/2</CODE>, <A NAME="IDX4743"></A> <CODE>eng_cut/1</CODE>, <A NAME="IDX4744"></A> <CODE>eng_release/1</CODE>, <A NAME="IDX4745"></A> <CODE>eng_wait/1</CODE>, <A NAME="IDX4746"></A> <CODE>eng_kill/1</CODE>, <A NAME="IDX4747"></A> <CODE>eng_killothers/0</CODE>, <A NAME="IDX4748"></A> <CODE>eng_self/1</CODE>, <A NAME="IDX4749"></A> <CODE>goal_id/1</CODE>, <A NAME="IDX4750"></A> <CODE>eng_goal_id/1</CODE>, <A NAME="IDX4751"></A> <CODE>eng_status/0</CODE>, <A NAME="IDX4752"></A> <CODE>lock_atom/1</CODE>, <A NAME="IDX4753"></A> <CODE>unlock_atom/1</CODE>, <A NAME="IDX4754"></A> <CODE>atom_lock_state/2</CODE>, <A NAME="IDX4755"></A> <CODE>concurrent/1</CODE>. </UL> <LI><STRONG>Other modules used:</STRONG> <UL> <LI><EM>System library modules:</EM> <A NAME="IDX4756"></A> <CODE>prolog_sys</CODE>. </UL> </UL> </div class="cartouche"> <H2><A NAME="SEC370" HREF="ciao_toc.html#TOC370">Documentation on exports (<CODE>concurrency</CODE>)</A></H2> <P> <A NAME="IDX4757"></A> <A NAME="IDX4758"></A> <DL> <DT><span class="define">PREDICATE:</span> <B>eng_call/4:</B> <DD><A NAME="IDX4759"></A> <P> <EM>Meta-predicate</EM> with arguments: <CODE>eng_call(goal,?,?,?)</CODE>. <P> <STRONG>Usage:</STRONG> <CODE>eng_call(+Goal, +EngineCreation, +ThreadCreation, -GoalId)</CODE> <UL> <LI><EM>Description:</EM> Calls <CODE>Goal</CODE> in a new engine (stack set), possibly using a new thread, and returns a <CODE>GoalId</CODE> to designate this new goal henceforth. <CODE>EngineCreation</CODE> can be either <CODE>wait</CODE> or <CODE>create</CODE>; the distinction is not yet meaningful. <CODE>ThreadCreation</CODE> can be one of <CODE>self</CODE>, <CODE>wait</CODE>, or <CODE>create</CODE>. In the first case the creating thread is used to execute <CODE>Goal</CODE>, and thus it has to wait until its first result or failure. The call will fail if <CODE>Goal</CODE> fails, and succeed otherwise. However, the call will always suceed when a remote thread is started. The space and identifiers reclaimed for the thread must be explicitly deallocated by calling <A NAME="IDX4760"></A> <CODE>eng_release/1</CODE>. <CODE>GoalId</CODE>s are unique in each execution of a Ciao Prolog program. <LI><EM>The following properties should hold at call time:</EM> <CODE>+Goal</CODE> is a term which represents a goal, i.e., an atom or a structure. (<CODE>basic_props:callable/1</CODE>) <CODE>+EngineCreation</CODE> is an atom. (<CODE>basic_props:atm/1</CODE>) <CODE>+ThreadCreation</CODE> is an atom. (<CODE>basic_props:atm/1</CODE>) <CODE>-GoalId</CODE> is an integer. (<CODE>basic_props:int/1</CODE>) </UL> </DL> <P> <A NAME="IDX4761"></A> <A NAME="IDX4762"></A> <DL> <DT><span class="define">PREDICATE:</span> <B>eng_call/3:</B> <DD><A NAME="IDX4763"></A> <P> <EM>Meta-predicate</EM> with arguments: <CODE>eng_call(goal,?,?)</CODE>. <P> <STRONG>Usage:</STRONG> <CODE>eng_call(+Goal, +EngineCreation, +ThreadCreation)</CODE> <UL> <LI><EM>Description:</EM> Similar to <A NAME="IDX4764"></A> <CODE>eng_call/4</CODE>, but the thread (if created) and stack areas are automatically released upon success or failure of the goal. No <CODE>GoalId</CODE> is provided for further interaction with the goal. <LI><EM>The following properties should hold at call time:</EM> <CODE>+Goal</CODE> is a term which represents a goal, i.e., an atom or a structure. (<CODE>basic_props:callable/1</CODE>) <CODE>+EngineCreation</CODE> is an atom. (<CODE>basic_props:atm/1</CODE>) <CODE>+ThreadCreation</CODE> is an atom. (<CODE>basic_props:atm/1</CODE>) </UL> </DL> <P> <A NAME="IDX4765"></A> <A NAME="IDX4766"></A> <DL> <DT><span class="define">PREDICATE:</span> <B>eng_backtrack/2:</B> <DD><A NAME="IDX4767"></A> <P> <STRONG>Usage:</STRONG> <CODE>eng_backtrack(+GoalId, +ThreadCreation)</CODE> <UL> <LI><EM>Description:</EM> Performs backtracking on the goal designed by <CODE>GoalId</CODE>. A new thread can be used to perform backtracking, according to <CODE>ThreadCreation</CODE> (same as in <A NAME="IDX4768"></A> <CODE>eng_call/4</CODE>). Fails if the goal is backtracked over by the local thread, and there are no more solutions. Always succeeds if executed by a remote thread. The engine is <STRONG>not</STRONG> automatically released up upon failure: <A NAME="IDX4769"></A> <CODE>eng_release/1</CODE> must be called to that end. <LI><EM>The following properties should hold at call time:</EM> <CODE>+GoalId</CODE> is an integer. (<CODE>basic_props:int/1</CODE>) <CODE>+ThreadCreation</CODE> is an atom. (<CODE>basic_props:atm/1</CODE>) </UL> </DL> <P> <A NAME="IDX4770"></A> <A NAME="IDX4771"></A> <DL> <DT><span class="define">PREDICATE:</span> <B>eng_cut/1:</B> <DD><A NAME="IDX4772"></A> <P> <STRONG>Usage:</STRONG> <CODE>eng_cut(+GoalId)</CODE> <UL> <LI><EM>Description:</EM> Performs a <EM>cut</EM> in the execution of the goal <CODE>GoalId</CODE>. The next call to <A NAME="IDX4773"></A> <CODE>eng_backtrack/2</CODE> will therefore backtrack all the way and fail. <LI><EM>The following properties should hold at call time:</EM> <CODE>+GoalId</CODE> is an integer. (<CODE>basic_props:int/1</CODE>) </UL> </DL> <P> <A NAME="IDX4774"></A> <A NAME="IDX4775"></A> <DL> <DT><span class="define">PREDICATE:</span> <B>eng_release/1:</B> <DD><A NAME="IDX4776"></A> <P> <STRONG>Usage:</STRONG> <CODE>eng_release(+GoalId)</CODE> <UL> <LI><EM>Description:</EM> Cleans up and releases the engine executing the goal designed by <CODE>GoalId</CODE>. The engine must be idle, i.e., currently not exedcuting any goal. <A NAME="IDX4777"></A> <CODE>eng_wait/1</CODE> can be used to ensure this. <LI><EM>The following properties should hold at call time:</EM> <CODE>+GoalId</CODE> is an integer. (<CODE>basic_props:int/1</CODE>) </UL> </DL> <P> <A NAME="IDX4778"></A> <A NAME="IDX4779"></A> <DL> <DT><span class="define">PREDICATE:</span> <B>eng_wait/1:</B> <DD><A NAME="IDX4780"></A> <P> <STRONG>Usage:</STRONG> <CODE>eng_wait(+GoalId)</CODE> <UL> <LI><EM>Description:</EM> Waits for the engine executing the goal denoted by <CODE>GoalId</CODE> to finish the computation (i.e., it has finished searching for a solution, either with success or failure). <LI><EM>The following properties should hold at call time:</EM> <CODE>+GoalId</CODE> is an integer. (<CODE>basic_props:int/1</CODE>) </UL> </DL> <P> <A NAME="IDX4781"></A> <A NAME="IDX4782"></A> <DL> <DT><span class="define">PREDICATE:</span> <B>eng_kill/1:</B> <DD><A NAME="IDX4783"></A> <P> <STRONG>Usage:</STRONG> <CODE>eng_kill(+GoalId)</CODE> <UL> <LI><EM>Description:</EM> Kills the thread executing <CODE>GoalId</CODE> (if any), and frees the memory used up by the stack set. Usually one should wait ( <A NAME="IDX4784"></A> <CODE>eng_wait/1</CODE>) for a goal, and then release it, but killing the thread explicitly allows recovering from error states. A goal cannot kill itself. This feature should be used with caution, because there are situations where killing a thread might render the system in an unstable state. Threads should cooperate in their killing, but if the killed thread is blocked in a I/O operation, or inside an internal critical region, this cooperation is not possible and the system, although stopped, might very well end up in a incosistent state. <LI><EM>The following properties should hold at call time:</EM> <CODE>+GoalId</CODE> is an integer. (<CODE>basic_props:int/1</CODE>) </UL> </DL> <P> <A NAME="IDX4785"></A> <A NAME="IDX4786"></A> <DL> <DT><span class="define">PREDICATE:</span> <B>eng_killothers/0:</B> <DD><A NAME="IDX4787"></A> <P> <STRONG>Usage:</STRONG> <UL> <LI><EM>Description:</EM> Kills threads and releases stack sets of all active goals, but the one calling <A NAME="IDX4788"></A> <CODE>eng_killothers</CODE>. Again, a safety measure. The same cautions as with <A NAME="IDX4789"></A> <CODE>eng_kill/1</CODE> should be taken. </UL> </DL> <P> <A NAME="IDX4790"></A> <A NAME="IDX4791"></A> <DL> <DT><span class="define">PREDICATE:</span> <B>eng_self/1:</B> <DD><A NAME="IDX4792"></A> <P> <STRONG>Usage:</STRONG> <CODE>eng_self(?GoalId)</CODE> <UL> <LI><EM>Description:</EM> <CODE>GoalId</CODE> is unified with the identifier of the goal within which <A NAME="IDX4793"></A> <CODE>eng_self/1</CODE> is executed. <A NAME="IDX4794"></A> <CODE>eng_self/1</CODE> is deprecated, and eng_goal_id/1 should be used instead. <LI><EM>The following properties should hold at call time:</EM> <CODE>?GoalId</CODE> is an integer. (<CODE>basic_props:int/1</CODE>) </UL> </DL> <P> <A NAME="IDX4795"></A> <A NAME="IDX4796"></A> <DL> <DT><span class="define">PREDICATE:</span> <B>goal_id/1:</B> <DD><A NAME="IDX4797"></A> <P> <STRONG>Usage:</STRONG> <CODE>goal_id(?GoalId)</CODE> <UL> <LI><EM>Description:</EM> <CODE>GoalId</CODE> is unified with the identifier of the goal within which <A NAME="IDX4798"></A> <CODE>goal_id/1</CODE> is executed. <A NAME="IDX4799"></A> <CODE>goal_id/1</CODE> is deprecated, and eng_goal_id/1 should be used instead. <LI><EM>The following properties should hold at call time:</EM> <CODE>?GoalId</CODE> is an integer. (<CODE>basic_props:int/1</CODE>) </UL> </DL> <P> <A NAME="IDX4800"></A> <A NAME="IDX4801"></A> <DL> <DT><span class="define">PREDICATE:</span> <B>eng_goal_id/1:</B> <DD><A NAME="IDX4802"></A> <P> <STRONG>Usage:</STRONG> <CODE>eng_goal_id(?GoalId)</CODE> <UL> <LI><EM>Description:</EM> <CODE>GoalId</CODE> is unified with the identifier of the goal within which <A NAME="IDX4803"></A> <CODE>eng_goal_id/1</CODE> is executed. <LI><EM>The following properties should hold at call time:</EM> <CODE>?GoalId</CODE> is an integer. (<CODE>basic_props:int/1</CODE>) </UL> </DL> <P> <A NAME="IDX4804"></A> <A NAME="IDX4805"></A> <DL> <DT><span class="define">PREDICATE:</span> <B>eng_status/0:</B> <DD><A NAME="IDX4806"></A> <P> <STRONG>Usage:</STRONG> <UL> <LI><EM>Description:</EM> Prints to standard output the current status of the stack sets. </UL> </DL> <P> <A NAME="IDX4807"></A> <A NAME="IDX4808"></A> <DL> <DT><span class="define">PREDICATE:</span> <B>lock_atom/1:</B> <DD><A NAME="IDX4809"></A> <P> <STRONG>Usage:</STRONG> <CODE>lock_atom(+Atom)</CODE> <UL> <LI><EM>Description:</EM> The <A NAME="IDX4810"></A> semaphore associated to <CODE>Atom</CODE> is accessed; if its value is nonzero, it is atomically decremented and the execution of this thread proceeds. Otherwise, the goal waits until a nonzero value is reached. The semaphore is then atomically decremented and the execution of this thread proceeds. <LI><EM>The following properties should hold at call time:</EM> <CODE>+Atom</CODE> is an atom. (<CODE>basic_props:atm/1</CODE>) </UL> </DL> <P> <A NAME="IDX4811"></A> <A NAME="IDX4812"></A> <DL> <DT><span class="define">PREDICATE:</span> <B>unlock_atom/1:</B> <DD><A NAME="IDX4813"></A> <P> <STRONG>Usage:</STRONG> <CODE>unlock_atom(+Atom)</CODE> <UL> <LI><EM>Description:</EM> The <A NAME="IDX4814"></A> semaphore associated to <CODE>Atom</CODE> is atomically incremented. <LI><EM>The following properties should hold at call time:</EM> <CODE>+Atom</CODE> is an atom. (<CODE>basic_props:atm/1</CODE>) </UL> </DL> <P> <A NAME="IDX4815"></A> <A NAME="IDX4816"></A> <DL> <DT><span class="define">PREDICATE:</span> <B>atom_lock_state/2:</B> <DD><A NAME="IDX4817"></A> <P> <STRONG>Usage 1:</STRONG> <CODE>atom_lock_state(+Atom, +Value)</CODE> <UL> <LI><EM>Description:</EM> Sets the semaphore associated to <CODE>Atom</CODE> to <CODE>Value</CODE>. This is usually done at the beginning of the execution, but can be executed at any time. If not called, semaphore associated to atoms are by default inited to 1. It should be used with caution: arbitrary use can transform programs using locks in a mess of internal relations. The change of a semaphore value in a place other than the initialization stage of a program is <STRONG>not</STRONG> among the allowed operations as defined by Dijkstra [Dij65,BA82]. <LI><EM>The following properties should hold at call time:</EM> <CODE>+Atom</CODE> is an atom. (<CODE>basic_props:atm/1</CODE>) <CODE>+Value</CODE> is an integer. (<CODE>basic_props:int/1</CODE>) </UL> <P> <STRONG>Usage 2:</STRONG> <CODE>atom_lock_state(+Atom, -Value)</CODE> <UL> <LI><EM>Description:</EM> Consults the <CODE>Value</CODE> of the semaphore associated to <CODE>Atom</CODE>. Use sparingly and mainly as a medium to check state correctness. Not among the operations on semaphore by Djikstra. <LI><EM>The following properties should hold at call time:</EM> <CODE>+Atom</CODE> is an atom. (<CODE>basic_props:atm/1</CODE>) <CODE>-Value</CODE> is an integer. (<CODE>basic_props:int/1</CODE>) </UL> </DL> <P> <A NAME="IDX4818"></A> <A NAME="IDX4819"></A> <DL> <DT><span class="define">PREDICATE:</span> <B>concurrent/1:</B> <DD><A NAME="IDX4820"></A> <P> <CODE>concurrent F/A</CODE> <P> The predicate named <CODE>F</CODE> with arity <CODE>A</CODE> is made <A NAME="IDX4821"></A> concurrent in the current module at runtime (useful for predicate names generated on-the-fly). This difficults a better compile-time analysis, but in turn offers more flexibility to applications. It is also faster for some applications: if several agents have to share data in a stuctured fashion (e.g., the generator knows and wants to restrict the data generated to a set of other threads), a possibility is to use the same concurrent fact and emply a field within the fact to distinguish the receiver/sender. This can cause many threads to access and wait on the same fact, which in turns can create contention problems. It is much better to create a new concurrent fact and to use that new name as a channel to communicate the different threads. <A NAME="IDX4822"></A> <CODE>concurrent/1</CODE> can either be given a <A NAME="IDX4823"></A> predicate spec in the form <CODE>Name/Arity</CODE>, with <CODE>Name</CODE> and <CODE>Arity</CODE> bound, or to give a value only to <CODE>Arity</CODE>, and let the system choose a new, unused <CODE>Name</CODE> for the fact. </DL> <H2><A NAME="SEC371" HREF="ciao_toc.html#TOC371">Known bugs and planned improvements (<CODE>concurrency</CODE>)</A></H2> <UL> <LI> Available only for Windows 32 environments and for architectures implementing POSIX threads. <LI> Some implementation of threads have a limit on the total number of threads that can be created by a process. Thread creation, in this case, just hangs. A better solution is planned for the future. <LI> Creating many concurrent facts may fill up the atom table, causing Ciao Prolog to abort. </UL> <P><HR><P> Go to the <A HREF="ciao_1.html">first</A>, <A HREF="ciao_86.html">previous</A>, <A HREF="ciao_88.html">next</A>, <A HREF="ciao_241.html">last</A> section, <A HREF="ciao_toc.html">table of contents</A>. </BODY> </HTML>
