Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.cplire.ru/Lab144/start/e_reside.html
Дата изменения: Mon Sep 24 15:02:27 2007
Дата индексирования: Tue Oct 2 03:37:55 2012
Кодировка:

Поисковые слова: п п п п п п п п п п п п п п
Actor Prolog User Guide. Residents.

Residents

In Actor Prolog a resident is a special mechanism that helps processes to inspect state of other processes. A resident observes the state of a specified (target) process and if the state of the process changes (for instance, after message handling) it proves a specified predicate of the process. It collects all found solutions into a list and sends this list to the process that owns the resident. To pass the list of solutions the resident uses flow messaging mechanism. Residents are very powerful language means; they play an important role in component-oriented and visual programming.

Let us consider the R1.A example of resident use in the Concur directory.

Example 1. Definition of resident.

-------------------------------------------
-- An example of Actor Prolog program.   --
-- (c) 2002, Alexei A. Morozov, IRE RAS. --
-- A resident.                           --
-------------------------------------------
project: (('R1'))
-------------------------------------------

The instance of the 'R1' class contains two processes: p1 and p2. The process p2 watches the process p1 by means of a resident. The definition of the resident is implemented with the "??" infix. The target process is put before the infix, and a predicate that has to be proven is put after the infix. Note that the definition of the resident is assigned as the initial value to the slot data of the process p2. This means that the slot data will be used as a common variable and the resident would send collected information to its owner via this variable. It is considered that residents send data via some protected ports.

class 'R1':
--
p1      = (('Target'));
p2      = (('Observer',
                data= p1 ?? f(1,2,3,4)
                ));
--
[
goal.
]
-------------------------------------------

The 'Target' class is derived from the 'Alpha' predefined class that implements some arithmetical functions. One of them, arithmetical addition, is used in the definition of the f predicate that will be proven by the resident. The f predicate imitates function that returns some values. For that the "=" delimiter is used in the heading of the clause. Predicates called by residents always have to be written as functions. Note that the f function is non-deterministic one and three solutions will be obtained as the result of its proof.

class 'Target' specializing 'Alpha':
[
goal.
--
f(_,_,C,D)= C + D.
f(A,B,C,D)= A + B + C + D.
f(A,B,_,_)= A + B.
]
-------------------------------------------

The 'Observer' class prints in the text window information incoming through the slot data.

class 'Observer' specializing 'Report':
--
data;
--
[
goal:-
        writeln("Received data:"),
        set_color('Blue'),
        writeln(data),
        set_color('Black').
]
-------------------------------------------

The process, the resident, and the common variable linking them can be shown graphically:



Fig. 1. Graphical depiction of resident.

That is printed on the screen by the program:



Fig. 2. Work of the resident.

At first, when the process p2 printed unbound variable resident did not give any data. As the process p2 received a list of values of the f function of the process p1 it printed the value of the variable again. Note that the resident has ordered the list of sent values. Moreover, according to the semantics of Actor Prolog residents delete all repeated elements from the lists of solutions.

Resident can watch several processes at once. For that it is enough to assign a slot in resident definition before the "??" infix; the slot must contain a list (or another complex term) that contains necessary target processes. In this case the resident will prove the specified predicate in all target worlds and send to its owner specified term in that corresponding lists of solutions are substituted for target processes.

Let us consider the R3.A example in the Concur directory.

Example 2. A resident inspecting a set of target processes.

-------------------------------------------
-- An example of Actor Prolog program.   --
-- (c) 2002, Alexei A. Morozov, IRE RAS. --
-- A resident inspecting a set of target --
-- processes.                            --
-------------------------------------------
project: (('Observer'))
-------------------------------------------
class 'Observer' specializing 'Report':
--
w1      = (('P1'));
w2      = (('P2'));
w3      = (('P3'));
--
target  = [w1,w2,w3];
result  = target ?? function(1,2,3);
[
goal:-
        writeln("Collected data:"),
        set_color('Blue'),
        writeln(result),
        set_color('Black').
]
-------------------------------------------
class 'P1' specializing 'Alpha':
[
goal.
--
function(_,_,_)= "From P1".
function(A,_,_)= A * 100.
]
-------------------------------------------
class 'P2' specializing 'Alpha':
[
goal.
--
function(_,_,_)= "From P2".
function(_,B,_)= B * 200.
]
-------------------------------------------
class 'P3' specializing 'Alpha':
[
goal.
--
function(_,_,_)= "From P3".
function(_,_,C)= C * 300.
]
-------------------------------------------

Here are recommended graphical notation for residents with several target processes:



Fig. 3. A resident with three target processes.

The program prints on the screen the following:



Fig. 4. Collection of information about several target processes.

The resident has substituted corresponding lists of values of function for the processes in the list [w1,w2,w3] and sent this list to its owner that is an instance of the 'Observer' class.

Residents react not only on change of state of target processes. Any change of the list of target processes or arguments of resident function results in activation of the resident and repeated collection of information in the target worlds.

A logical status of mechanism of residents in Actor Prolog depends on how they are used in a program. Accurate use of residents allows one to create concurrent programs implementing exhaustive search and having strict model-theoretic semantics.

Table of content