Concurrent LISP on a Multi-Micro-Processor System - ijcai

2 downloads 88 Views 199KB Size Report
CONCURRENT LISP ON A MULTI-MICRO-PROCESSOR SYSTEM. Shigeo Sugimoto*, Koichi Tabata**,. *Department of Information. Science. Kyoto University.
CONCURRENT LISP ON A MULTI-MICRO-PROCESSOR SYSTEM

Shigeo S u g i m o t o * ,

Koichi

Tabata**, Kiyoshi

*Department o f I n f o r m a t i o n Science Kyoto U n i v e r s i t y K y o t o , 606 Japan

**

ABSTRACT

INTRODUCTION "We assume t h a t t h e r e is a s e a r c h t r e e . Each path on a t r e e is a l l o c a t e d to a search process. Each s e a r c h p r o c e s s goes a l o n g i t s g i v e n p a t h u n t i l it f i n d s a g o a l or a boundary. When . a l l search p r o c e s s e s f i n d t h e b o u n d a r y , t h e n t h e best N s e a r c h processes are to be s e l e c t e d to c o n t i n u e searching forward. Thi3 a c t i v i t y repeats until a process f i n d s the g o a l . "

T h i s paper proposes a new c o n c u r r e n t p r o g r a m ming l a n g u a g e , C o n c u r r e n t L I S P , and a m u l t i - m i c r o processor system for it. We have developed Concurrent LISP for the purpose of a p p l y i n g m u l t i p r o c e s s i n g mechanism to A I programs, LISP is t h e most p o p u l a r language used f o r AI applications. Many A I systems a r e w r i t t e n i n L I S P . S e v e r a l AI languages have been developed on t h e b a s i s of L I S P , such as PLANNER, CONNIVER and s0 o n . These languages have b u i l t - i n f a c i l i t i e s o f b a c k tracking and c o r o u t i n e s f o r f l e x i b l e and e f f i c i e n t searching to solve problems. However, t h e s e f a c i l i t i e s have d i s a d v a n t a g e s ; backtracking is too r e s t r i c t i v e because an abandoned path on a s e a r c h t r e e can not be r e - s e a r c h e d , and c o r o u t i n e s may be complicated due to transfer of control among coroutines.

Fig.1 shows the o u t l i n e s of both a multiprocess program and a c o r o u t i n e program f o r the search problem. There a r e two t y p e s o f p r o c e s s , m o n i t o r p r o c e s s and s e a r c h p r o c e s s . I n t h e case o f t h e m u l t i - p r o c e s s program ( F i g . 1 ( a ) ) , every search p r o c e s s proceeds concurrently along their given paths, t h e n t h e y reach a boundary or a g o a l where they communicate with the monitor process via shared v a r i a b l e s or messages. There is no need to write operations for transfer of control between processes. Thus, each process i s dedicated to i t s own t a s k .

Multi-process f a c i l i t i e s are considered to be b e t t e r f o r s o l v i n g s e a r c h problems t h a n backtracki n g / c o r o u t i n e f a c i l i t i e s , from the standpoint of f l e x i b l e s e a r c h , h i g h m o d u l a r i t y and s i m p l e program structure. M u l t i - p r o c e s s mechanism may be i m p l e mented i n t h e e n v i r o n m e n t s of p a r a l l e l processing t o p r o v i d e g r e a t c o m p u t a t i o n power f o r A I p r o b l e m s . These f a c t s have l e d us to d e s i g n a new LISP with m u l t i - p r o c e s s mechanism called Concurrent L I S P [ 8 ] and a m u l t i - m i c r o - p r o c e s s o r system f o r i t .

I n t h e case o f a c o r o u t i n e program ( F i g . 1 ( b ) ) , on the o t h e r hand, search c o r o u t i n e s and t h e monitor coroutine communicate w i t h each o t h e r b y means of RESUME o p e r a t i o n . The m o n i t o r c o r o u t i n e s e l e c t s a search c o r o u t i n e a c c o r d i n g t o t h e agenda and resumes t h e e x e c u t i o n o f t h e s e l e c t e d c o r o u t i n e . The s e l e c t e d search c o r o u t i n e searches i t s given path u n t i l i t f i n d s t h e boundary o r t h e g o a l , then i t resumes the execution of the monitor c o r o u t i n e . Therefore, each c o r o u t i n e must keep t r a c k of not only i t s own t a s k , but also t h e next coroutine whose e x e c u t i o n i s t o b e resumed*

II MULTIPROCESSING FOR AI A. B a c k t r a c k i n g ,

Educational Center f o r Information Processing Kyoto U n i v e r s i t y K y o t o , 606 Japan

i n g i s e x p e n s i v e and r e s t r i c t i v e since it follows d e p t h f i r s t s e a r c h method and an abandoned p a t h on a s e a r c h t r e e can not be r e - s e a r c h e d [ 7 ] . C o r o u t i n e f a c i l i t i e s provided in several LISP systems are convenient f o r s e l e c t i n g a path which i s l i k e l y t o reach a g o a l . Several AI systems p e r f o r m t h e i r tasks efficiently by using coroutine f a c i l i t i e s w i t h a s c h e d u l i n g t a b l e c a l l e d agenda* A disadvantage of c o r o u t i n e s i s t h a t c o n t r o l t r a n s f e r among coroutines makes program s t r u c t u r e complicated. Multi-process facilities provide us higher modul a r i t y of control s t r u c t u r e than c o r o u t i n e ones. Comparison o f c o r o u t i n e f a c i l i t i e s w i t h m u l t i - p r o c ess f a c i l i t i e s o n a s i m p l e example i s p r e s e n t e d :

For s o l v i n g search problems in AI field, multi-process d e s c r i p t i o n is more e l e g a n t t h a n t h e b a c k t r a c k i n g / c o r o u t i n e d e s c r i p t i o n , from t h e s t a n d point of f l e x i b l e search, high modularity and s i m p l e program s t r u c t u r e . We propose t h e language specification of Concurrent LISP, which is a c o n c u r r e n t programming language based on L I S P . We have implemented its interpreter on a large scale computer. We a r e w o r k i n g at t h e i m p l e m e n t a t i o n of its interpreter o n m u l t i - m i c r o - p r o c e s s o r system t o realize further efficient execution, 1

Agusa* and Yutaka Ohno*

C o r o u t i n e s and M u l t i p r o c e s s i n g

Backtracking i3 a conventional technique for p r o b l e m s o l v i n g , i . e . t r i a l and e r r o r method, Many LISP systems have b a c k t r a c k i n g f a c i l i t i e s 3uch as FAIL and FAILSET o p e r a t i o n * In g e n e r a l , b a c k t r a c k -

B. Models and M u l t i - p r o c e s s Programs From t h e v i e w p o i n t of p r o g r a m m i n g , first we u s u a l l y b u i l d models f o r g i v e n problems and t h e n we

949

derive programs from the models. S i n c e models u s u a l l y c o n s i s t of many components, we must c l a r i f y what a r e components, what t h e components do and what r e l a t i o n s e x i s t among t h e components. If the components a r e a c t i v a t e d s e q u e n t i a l l y , a component may be implemented as a subroutine. If t h e components coexist with others, a component may be implemented as a coroutine or a process in a m u l t i - p r o c e s s system. I n A I f i e l d , s e v e r a l modeling p r i n c i p l e s have been used w i d e l y , e*g. production s y s t e m s , a c t o r s and s o o n . T o d e r i v e programs f r o m models b u i l t w i t h t h o s e principles, Multi-process d e s c r i p t i o n i s more e l e g a n t than the convetional d e s c r i p t i o n t e c h n i q u e s because o f t h e m o d u l a r i t y o f programs and the adaptability for parallel processing. Ill A.

"A process is an e n t i t y which e v a l u a t e s a form self-containedly." The process called the main process is a c t i v a t e d when e v a l u a t i o n o f a t o p - l e v e l d o u b l e t , a kind of form, starts. A non-main process is activated when the process activation function STARTEVAL is e x e c u t e d * We d e f i n e s e v e r a l p r o p e r t i e s of a p r o c e s s as f o l l o w s : 1) A process is a c t i v a t e d by its parent process e x c e p t f o r t h e main p r o c e s s . The main process is a c t i v a t e d i n the i n t e r p r e t i n g l o o p , 2 ) A p r o c e s s t e r m i n a t e s when i t f i n i s h e s e v a l u a t i o n of the given form or its parent terminates. The value of the form evaluated by the process is c a l l e d "process v a l u e " of the process. 3) I n i t i a l environments of a process is the e n v i r o n m e n t s o f i t s p a r e n t p r o c e s s when t h e parent e x e c u t e s STARTEVAL* 4) Every process has a u n i q u e number g i v e n by the interpreter and its own name for user's convenience* In p a r t i c u l a r , t h e main p r o c e s s has name "MAIN" and number 1.

CONCURRENT LISP

Outline

C o n c u r r e n t LISP is a concurrent programming l a n g u a g e baaed o n LISP. It is designed without changing the o r i g i n a l language features of LISP* For e x a m p l e , (1) l i t e r a l atoms a r e unique, (2) functional notation is preserved, (3) dynamic b i n d i n g s t r a t e g y i s used and s o o n .

The p r o c e s s a c t i v a t i o n defined below.

The c u r r e n t v e r s i o n o f C o n c u r r e n t LISP f o l l o w s LISP 1 . 5 [ 3 ] . I n a d d i t i o n t o t h e o r d i n a r y LISP f u n c tions, C o n c u r r e n t LISP has t h r e e p r i m i t i v e c o n c u r r e n t f u n c t i o n s and s p e c i a l f u n c t i o n s to manipulate data attached to processes. The three primitive f u n c t i o n s a r e STARTEVAL f o r p r o c e s s a c t i v a t i o n , CR ( C r i t i c a l Region function) and CCR (Conditional C r i t i c a l Region f u n c t i o n ) for mutual e x c l u s i o n * B.

Process

A multi-process system w r i t t e n i n Concurrent LISP is a set o f many cooperating sequential processes, each o f w h i c h e v a l u a t e s i t s g i v e n f o r m . We d e f i n e a " p r o c e s s " in C o n c u r r e n t LISP as f o l l o w s :

950

function

STARTEVAL

is

s t a r t e v a l [ p r o c 1;proc2; • ;procn] proci = l i s t [ n a m e i ; f o r m i ] , namei = name of i ' t h son p r o c e s s , f o r m i = f o r m t o b e e v a l u a t e d b y i ' t h son p r o c e s s . When a p r o c e s s e x e c u t e s STARTEVAL, t h e process a c t i v a t e s n son p r o c e s s e s . Each son p r o c e s s has i t s own name s p e c i f i e d by name and e v a l u a t e s f o r m . The v a l u e o f STARTEVAL is a list of names of son processes; s t a r t e v a l [ p r o c i ; p r o c 2 ; • • ;procn] = list[namei;name2; • ;namen]„ Name must be a f o r m whose v a l u e is a l i t e r a l atom. Form may be any t y p e of f o r m (a c o n s t a n t , a variable or an e x p r e s s i o n ) * When form is an e x p r e s s i o n , by the parent process a c t u a l parameters

are processed according to the function type of car[form ] and passed to the newly created process* The f o l l o w i n g form means activation of two processes, P and Q, which evaluate forms (F X) and (G Y) r e s p e c t i v e l y . (STARTEVAL ('P (F X)) ('Q (G Y)))

other processes are in suspended s t a t e . of c r [ f o r m ] is the value of form; c r [ f o r m ] = form.

The value

ccr[condition;form] A process waits u n t i l condition is neither NIL nor F, and evaluates form with the exclusive r i g h t s to access the data area shared among processes. (Condition means wait condition for the process to synchronize with other processes.) Pseudo-functions must not appear in c o n d i t i o n . During evaluation of form, the process keeps the r i g h t s except while it awaits the holding a c e r t a i n condition in form. The value of c c r [ c o n d i t i o n ; f o r m ] is the value of form; c c r [ c o n d i t i o n ; f o r m ] = form* Nesting of CR and CCR is allowed. Wait during e v a l uation of CR or CCR occurs due to the nested CCR. The following example shows interprocess communication using CR and CCR* Example: Process Q waits u n t i l a variable X becomes NIL and evaluates a form (F ARG). X is assumed to be shared between process P and Q. (CR (SETQ X NIL)) - process P (CCR (NULL X) (F ARG)) - process Q

Recursive a c t i v a t i o n of processes is permitted* The f o l l o w i n g example shows a function for computing f a c t o r i a l using recursive process a c t i v a t i o n . (FACT (LAMBDA (N) (COND ((ZEROP N) 1) (T ((LAMBDA (X) (TIMES N (CCR (TERMP X) (PROCVAL X ) ) ) ) (CAR (STARTEVAL ((GENSYM) (FACT (SUB1 N ) ) ) ) ) ) ) ) )) Data area used by processes is c l a s s i f i e d i n t o two types, s t a t i c and dynamic data area. Property l i s t s and process c o n t r o l blocks are s t a t i c , and association l i s t s and variable area a l l o c a t e d on c o n t r o l stacks are dynamic. Data stored in the s t a t i c area may be used by a l l processes. For example, bodies of functions are stored on property l i s t s and used by a l l processes. Data stored in the dynamic area are possessed by each process. For example, a lambda variable bound in a f u n c t i o n is allocated in the environments of the process which executes the f u n c t i o n * More than one process can use concurrently the same f u n c t i o n , which may be e i t h e r b u i l t - i n or defined f u n c t i o n , because variables bound in the function are possessed by each process.

D. Interprocess Communication Concurrent LISP

provides f o l l o w i n g objects to

Table 1 Functions to manipulate data on pcb's 1) functions which give a t r u t h value according to a process s t a t e t e r m p [ p ] : If a specified process, p, has already terminated then the value is T else NIL. w a i t p [ p ] : If a specified process, p, is w a i t i n g then the value is T else NIL. asonterm[p], osonterm[p]: If a l l or at least one of son processes of a s p e c i f i e d process, p, have terminated then the value is T else NIL. a s o n w a i t [ p ] , osonterm[p]: If a l l or at least one of son processes of a s p e c i f i e d process are waiting then the value is T else NIL. 2) functions which give a process number or a process name s e l f [ ] , parent[p], firstson[p], brother[p]: These functions return a process number of i t s e l f , a parent, a f i r s t son, or the next younger brother. s o n l i s t [ p ] : This function returns a l i s t of son process names of a process p. procname[p], procnum[p]: This function returns a process name or number of a s p e c i f i e d process. 3) functions which give process value(s) p r o c v a l [ p ] : This function returns a process value of a s p e c i f i e d process* s o n n v a l [ p ] : This function returns a process value l i s t of son processes specified process. 4) functions used for mailing between processes m a i l [ m e s ; p ] : This function appends the value of cons[self[];raes] to the contents of the mailbox of a process p* The value of t h i s function is mes. recmail[]: This function returns T if the mailbox of the concerned process is not empty else NIL. g e t r a a i l [ ] : This function returns contents of the mailbox of a concerned process. After execution of t h i s f u n c t i o n , the mail box is cleared.

Concurrent LISP has functions to manipulate data attached to processes, e . g . process names, process values and so on. They are called process data manipulation functions and l i s t e d in Table 1. C. Mutual Exclusion among Processes Concurrent programming languages need to provide f a c i l i t i e s f o r mutual exclusion to avoid i l l e g a l i n t e r a c t i o n among processes. Concurrent LISP has two p r i m i t i v e f u n c t i o n s , CR and CCR, which are shown below. The idea of CR and CCR is o r i g i n a t e d from [ 1 ] and modified to be adapted to the environments of LISP* The f a c i l i t i e s to express process synchronizat i o n and interprocess communication are the most important f a c i l i t i e s f o r concurrent programming languages* The two f u n c t i o n s , CR and CCR, have enough power to express process i n t e r a c t i o n s , such as P- and V- operator, Hoare's monitor, s e r i a l i z e r and guarded command* Moreover, t h e i r f u n c t i o n a l n o t a t i o n s t r i c t l y follows the o r i g i n a l language features of LISP* The functions CR and CCR are defined below* cr[form] A process evaluates form with the exclusive r i g h t s to access the data area shared among processes* During evaluation of form the process keeps the r i g h t s except while it awaits the holding a c e r t a i n c o n d i t i o n in form. (Such wait condition may appear in CCR*) While the process has the r i g h t s , a l l

951

express process synchronization and interprocess communication. U s i n g t h e s e o b j e c t s c o u p l e d w i t h CR and CCR p r i m i t i v e s , we can e a s i l y construct f u n c t i o n s f o r i n t e r p r o c e s s communication.

t i o n , garbage c o l l e c t i o n and so on). I n t e r p r e t e r processor ( I P i ) : A process operates on IPi to which it is allocated by the main OS. I/O processor (IOP): IOP performs I/O operation.

1) Shared v a r i a b l e Environments of a p a r e n t p r o c e s s can be shared among 3on p r o c e s s e s . Son p r o c e s s e s can r e f e r free v a r i a b l e s bound i n t h e e n v i r o n m e n t s o f t h e i r p a r e n t process. The example i n I I I . C . shows i n t e r p r o c e s s communication via a shared variable. Shared v a r i a b l e s are u s e f u l f o r communication in a family of processes. 2) Property l i s t In ordinary LISP, property lists of literal atoms a r e used f r e q u e n t l y a s s t a t i c d a t a area. In Concurrent LISP, p r o p e r t y l i s t s a r e used a s s t a t i c d a t a a r e a and a r e s h a r e d among a l l p r o c e s s e s . 3) M a i l i n g f u n c t i o n Concurrent LISP has functions called mailing functions for direct message passing between processes. In order to r e a l i z e mailing functions, we have p r o v i d e d a " m a i l b o x " field in a process c o n t r o l b l o c k ( p e b ) . See T a b l e 1 . Example: Process P send3 a message "OK" to p r o c e s s Q, and Q r e c e i v e s i t . (CR (MAIL 'OK ' Q ) ) - process P (CCR (RECMAIL) (SETQ BUF (GETMAIL))) - p r o c e s s Q

* memory PCB area: Pcb 's are 3tored on t h i s area. LIST area: List c e l l s are stored on t h i s area. Random Access (RA) area: Area for l i t e r a l atoms, numerals, arrays, s t r i n g s and so on. Stack area: Area for c o n t r o l stacks of processes.

E.

Concurrent

A separate memory should be provided for each of the above data areas in order to solve the bus bottleneck between common memory and m u l t i processors and to increase the maximum number of IP's i n s t a l l e d . Since, in Concurrent LISP programs, there may be many small processes a c t i v a t e d , the system is designed to accept about a thousand processes. We select 16-bit micro-processor MC68000 for MP and I P ' s . In [ 9 ] , which reports performance of LISP systems in Japan, the r a t i o of 1:100 was reported in the performance of a 8-bit micro-processor LISP machine to LISP i n t e r p r e t e r on a large scale computer. On the other hand, the range of r a t i o of performance of 68000 and the 8-bit micro-processor is about 1 0 : 1 - 2 0 : 1 . We expect our system c o n s i s t i n g of ten 68000's w i l l have equal performance to LISP system on a large scale computer.

LISP I n t e r p r e t e r

The C o n c u r r e n t LISP i n t e r p r e t e r executes a program w r i t t e n i n C o n c u r r e n t L I S P . The i n t e r p r e t e r repeats the f o l l o w i n g a c t i v i t y ( c a l l e d i n t e r p r e t i n g loop): 1) To read a t o p - l e v e l d o u b l e t , 2) To e v a l u a t e t h e d o u b l e t , and 3) To p r i n t out t h e p r o c e s s v a l u e s *

* language The s p e c i f i c a t i o n of Concurrent LISP is s l i g h t l y modified in order to be adapted to the multi-micro-processor system environment. The major m o d i f i c a t i o n is that CR and CCR p r i m i t i v e on a multi-micro-processor system w i l l have the form: cr [shared o b j e c t ; f o r m ] , and ccr[shared o b j e c t ; c o n d i t i o n ; f o r m ] . The number of processes running on I P ' s increases by t h i s m o d i f i c a t i o n , since c r i t i c a l region is divided i n t o several d i s j o i n t regions using shared object parameter. This m o d i f i c a t i o n imposes r e s t r i c t i o n on use of l i s t replacement f u n c t i o n s , i . e . RPLACA and RPLACD; these are to be eliminated from the set of functions a v a i l a b l e for users.

The main p r o c e s s i s a c t i v a t e d and terminates a t t h e second phase o f the activity. During the l i f e o f t h e main p r o c e s s , i t s descendant p r o c e s s e s a r e a c t i v a t e d and t e r m i n a t e .

1) 2) 3) 4) 5) 6)

The f o l l o w i n g s a r e m a j o r components, Process c o n t r o l b l o c k l i s t , Control stack, Association l i s t , Property l i s t , Schedule m o d u l e , and I n t e r p r e t module.

We have i m p l e m e n t e d t h e i n t e r p r e t e r on FACOM M-200 w i t h P L / I ( a b o u t 4800 l i n e s ) [ 6 ] . The c u r r e n t v e r s i o n has 140 b u i l t - i n f u n c t i o n s . IV MULTI-MICRO-PROCESSOR

SYSTEM

For r e a l i z a t i o n of f u r t h e r e f f i c i e n t program e x e c u t i o n of Concurrent LISP, we are w o r k i n g at implementation of i t s i n t e r p r e t e r on a m u l t i - m i c r o processor system.. The o v e r v i e w o f t h e system i s shown i n F i g . 2 . • processors Master p r o c e s s o r (MP): The main OS on MP p e r f o r m s process management, processor management, I/O management and memory management (stack a l l o c a -

952



(PROG () , DATA - t h e i n i t . b o a r d ( B r d ) . , END u s e d as a f l a g . (MK_PR_NAME DATA) ) ) ; NAMES - l i s t , o f names o f s e a r c h p r o c e s s e s (SP's). (STARTEVAL ( ' M O N I T ( M O N I T O R ) ) ) ; A c t i v a t e MONIT. (PUT (CAR NAMES) 'PROCESS 'PROCESS) ; Mark t h e B r d . (STARTEVAL ( ( C A R NAMES) (SEARCH ( L I S T DATA) 1 ) ) ) ; A c t v . S P . (CCR (TERMP 'MONIT) (PROGN ; W a i t u n t i l MONIT t e r m i n a t e s . (CSETQ END T ) ; Set end f l a g . (CCR (ASONTERM ( ) ) ; Wait u n t i l a l l SP's t e r m i n a t e . (RETURN (CAR (EVAL (PROCVAL ' M O N I T ) ( ) ) ) ) : Return Brd s e q . from i n i t i a l to g o a l .

(CR (WHILE T : (PROGN (CCR (EVAL (CONS

V

Do f o r e v e r 'AND

(MAPCAR NAMES ' W A I T P ) ) ( ) ) ; Wait u n t i l a l l SP's w a i t . (COND < ( E Q (SORT_SCORE) 'GOAL) ; G o a l h a s b e e n f o u n d ? (TERMINATE (CAR NAMES>)) ; R e t u r n p r o c . n a m e . (COND ((GREATERP (LENGTH NAMES) 3) ; M o r e t h a n 2 p r o c ' s ? (CSETQ DEPTH (PLUS DEPTH D E L T A ) ) ; C h a n g e b o u n d a r y . (MAPCAR ( L I S T (CAR NAMES)(CADR NAMES)(CADDR NAMES)) ' ( L A M B D A (X) ( M A I L 'CONT X ) ) ) ) ; R e s u m e . (T (CSETQ DEPTH (PLUS DEPTH D E L T A ) ) ; C h a n g e b o u n d a r y . (MAPCAR NAMES ' ( L A M B D A (X) ( M A I L 'CONT X ) ) ) ) ) (CCR (NOT (WAITP (CAR N A M E S ) ) ) N I L ) > ; S y n c h r o n i z a t i o n .

; C o n t i n u e s e a r c h i n g .

EXAMPLE

An example program f o r 8 - p u z z l e i s p r e s e n t e d . The board o f 8 - p u z z l e is represented as a l i s t of integer, Fig.3 shows t h e main p a r t o f t h e program to solve the p u z z l e . The strategy used i n this example f o l l o w s t h e s e a r c h model shown in II.A* During execution of the program, t h e r e e x i s t main process, MONIT process and s e a r c h p r o c e s s e s . The main process a c t i v a t e s MONIT p r o c e s s and the search process which examines the i n i t i a l boardMONIT p r o c e s s m o n i t o r s t h e s e a r c h p r o c e s s e s . When all search processes reach the boundary, MONIT s e l e c t s three processes, w h i c h a r e most l i k e l y to r e a c h t h e g o a l . From t h e i r boards g i v e n by their parent process, search processes s t a r t s e a r c h i n g . A s e a r c h p r o c e s s examines a board, expands it and activates its sons. Fig.4 and F i g , 5 show the r e s u l t s of the program e x e c u t i o n and relations among p r o c e s s e s r e s p e c t i v e l y . VI

CONCLUDING REMARKS

Multi-process d e s c r i p t i o n mechanism Is more elegant than the conventional d e s c r i p t i o n mechan i s m s , such a s b a c k t r a c k i n g and c o r o u t i n e descript i o n . S i n c e LISP i s a "common l a n g u a g e " i n A I f i e l d in a sense, we consider, i t i s necessary t o i n t r o duce LISP-based concurrent programming l a n g u a g e s which d o not change t h e o r i g i n a l language f e a t u r e s o f LISP such a s f u n c t i o n a l n o t a t i o n and s i m p l i c i t y *