Design Patterns for Multi-Threaded Logic Programming Languages Copyright © 1999, BinNet Corp. Paul Tarau University of North Texas & BinNet Corporation

Summary –Introduction/Motivation –Kernel Prolog = Horn Clauses + Engines –Threads as First-Order Objects –Blackboard Operations –Mobile Threads and Remote Execution –Key Design Patterns –Case Studies, Examples, Applications –Conclusion

Motivation –paradigm shift towards networked, mobile, ubiquitous computing with increasingly complex patterns of interaction –threads: needed for programming reactive/proactive mobile agents –back to pure LP - a good thing - but let’s give it an expressiveness lift:-) –Hilbert’s approach => reusable design patterns through an axiomatic reconstruction of frequently used components!

Design Patterns in the Object Oriented World Gamma, Helm, Johnson, Vlissides - sequentialGamma, Helm, Johnson, Vlissides - sequential Doug Lea: Multi-threaded Java Design PatternsDoug Lea: Multi-threaded Java Design Patterns Quickly growing library of patterns: strong influence on Java itselfQuickly growing library of patterns: strong influence on Java itself Pattern: encoding of expert experiencePattern: encoding of expert experience

Existing Design Patterns in LP –classic Prolog libraries, The Art of Prolog, The Craft of Prolog... –the expressive power of multi-threading has not been investigated in depth –new context: multi-threading comes as a mandatory requirement for client/server, network, Internet programming –multithreading brings back an old enemy: state

Patterns for Interoperating with NON-LP Components reduce/simplify state machine for the NON-LP componentreduce/simplify state machine for the NON-LP component introduce (minimal/clean/natural/simple) state machine on the LP sideintroduce (minimal/clean/natural/simple) state machine on the LP side use multi-threading LP: it allows to keep interoperation with NON-LP components modularuse multi-threading LP: it allows to keep interoperation with NON-LP components modular build an intuitive ontology for state in LPbuild an intuitive ontology for state in LP

Overview of Our Ontology Places: blackboards + a server thread listening on a portPlaces: blackboards + a server thread listening on a port Things: Prolog terms, in particular Prolog clausesThings: Prolog terms, in particular Prolog clauses Agents:Agents: –a set of mobile threads initiated by a unique goal at a given Place –coordination: through blackboards - some local, some remote

Overview of Our (Orthogonal) Execution Mechanisms enginesengines threadsthreads blackboard operationsblackboard operations –basic Linda coordination, associative search –blackboard constraints - –blackboard constraints - react when something becomes true mobile threads operations

Engines as Generalized Iterators: keep state minimal Engine = an LD Resolution Interpreter with first order control: constructor+iterator –new_engine(Goal,AnswerPattern, Handle): creates a new interpreter Handle solving Goal –new_answer(Handle,AnswerInstance): If AnswerInstance is no then stops the engine, otherwise either returns a new answer, of the form the(AnswerInstance) or returns no if there are no more answers.

Engine Operations: the fine print:-) –once no is returned by new_answer/2, all subsequent uses will return no –no bindings are propagated back to the original Goal or AnswerPattern by new_answer/2, (we first standardize apart the variables in Goal + AnswerPattern, then backtrack over its alternative answers) –the language engines can handle: Horn Clauses + new_engine/3 + new_answer/2 =>any engine can create new engines!

Built-ins as Design Patterns for Horn Clauses + Engines first_solution/1first_solution/1 once/1, not/1once/1, not/1 call/1call/1 if/3if/3 findall/3findall/3 copy_term/2, var/1copy_term/2, var/1

first_solution/1 % returns Answer=the(X0) or Answer=no as first solution of G first_solution(X,G,Answer):- new_engine(G,X,E), new_answer(E,R), Answer=R.

once/1 and not/1 % succeeds by binding G to its first solution or fails once(G):-first_solution(G,G,the(G)). % succeeds without binding G, if G fails not(G):-first_solution(_,G,no).

call/1 call(Goal):- new_engine(Goal,Goal,E),collect_call(E,Goal).call(Goal):- new_engine(Goal,Goal,E),collect_call(E,Goal). % backtracks over the answer sequence% backtracks over the answer sequence collect_call(E,Goal):- new_answer(E,the(Answer)), collect_more(E,Answer,Goal).collect_call(E,Goal):- new_answer(E,the(Answer)), collect_more(E,Answer,Goal). collect_more(_,Answer,Answer). collect_more(E,_,Answer):- collect_call(E,Answer).collect_more(_,Answer,Answer). collect_more(E,_,Answer):- collect_call(E,Answer).

if-the-else if(Cond,Then,Else):-first_solution( successful(Cond,Then),Cond,R), select_then_else(R,Cond,Then,Else).if(Cond,Then,Else):-first_solution( successful(Cond,Then),Cond,R), select_then_else(R,Cond,Then,Else). select_then_else( the(successful(Cond,Then)),Cond,Then,_ ):-call(Then).select_then_else( the(successful(Cond,Then)),Cond,Then,_ ):-call(Then). select_then_else(no,_,_,Else):-call(Else).select_then_else(no,_,_,Else):-call(Else).

findall/3 –findall(X,G,Xs):- new_engine(G,X,E), new_answer(E,Answer), collect_all_answers(Answer,E,Xs). –collect_all_answers(no,_,[]). collect_all_answers(the(X),E,[X|Xs]):- new_answer(E,Answer), collect_all_answers(Answer,E,Xs).

copy_term/2 and var/1 copy_term(X,CX):- first_solution(X,true,the(CX)).copy_term(X,CX):- first_solution(X,true,the(CX)). var(X):-copy_term(X,a), copy_term(X,b).var(X):-copy_term(X,a), copy_term(X,b).

Kernel Prolog = Horn Clauses + new_engine/3 + new_answer/2 building basic socket and file I/Obuilding basic socket and file I/O emulating the dynamic databaseemulating the dynamic database emulating XSB: variant_of/2 + coordination + blackboard operationsemulating XSB: variant_of/2 + coordination + blackboard operations _cgi/715/kernel_prolog/query.h tml

Encapsulating Engine Operations as Linear Assumptions ?- AnswerPattern Consumer?- AnswerPattern Consumer ?- AnswerPattern <= Producer?- AnswerPattern <= Producer Linear Assumptions of the from AnswerPattern: demand driven multiple answers generated by Producer - to be consumed lazily by ConsumerLinear Assumptions of the from AnswerPattern: demand driven multiple answers generated by Producer - to be consumed lazily by Consumer

Example: ?- a(X) (a(A),a(B),a(C), write([A,B,C]),nl).?- a(X) (a(A),a(B),a(C), write([A,B,C]),nl). Answer: [1,2,3]Answer: [1,2,3] Works like linear implication formula:Works like linear implication formula: a(1) -o a(2) -o a(3) -o ( a(A),a(B),a(C) )a(1) -o a(2) -o a(3) -o ( a(A),a(B),a(C) )

Reflective Meta Interpreter solve(G):- once(reduce(G,NewG)), call(NewG).solve(G):- once(reduce(G,NewG)), call(NewG). reduce(G,G):-is_builtin(G). reduce(','(A,B),','(solve(A),solve(B))). reduce(G,','(clause(G,Gs),solve(Gs))).reduce(G,G):-is_builtin(G). reduce(','(A,B),','(solve(A),solve(B))). reduce(G,','(clause(G,Gs),solve(Gs))).

Thread Operations: minimal! bg(Goal,ThreadHandle): runs a thread initiated by Goal and returns a handlebg(Goal,ThreadHandle): runs a thread initiated by Goal and returns a handle thread_clone(CloneThreadHandle)thread_clone(CloneThreadHandle) thread_join(T): wait for T to finishthread_join(T): wait for T to finish thread_sleep(Duration), thread_this(ThisThreadHandle)thread_sleep(Duration), thread_this(ThisThreadHandle) thread_resume/1, thread_suspend/1thread_resume/1, thread_suspend/1

Basic Linda Operations out(X): puts X on the blackboardout(X): puts X on the blackboard in(X): waits until it can take an object matching X from the blackboardin(X): waits until it can take an object matching X from the blackboard all(X,Xs): reads the list Xs matching X currently on the blackboardall(X,Xs): reads the list Xs matching X currently on the blackboard derived operations: cin/1, rd/1derived operations: cin/1, rd/1

Implementing in/1, out/1 with suspend and resume in Jinni and BinProlog this is in the implementation language but, in fact, it could be at source levelin Jinni and BinProlog this is in the implementation language but, in fact, it could be at source level in(X): if X is on the blackboard take it, if not add waiting(X,ThisThread) and do suspend(ThisThread)in(X): if X is on the blackboard take it, if not add waiting(X,ThisThread) and do suspend(ThisThread) out(X): if waiting(X,T) matches, take it and call resume(T)out(X): if waiting(X,T) matches, take it and call resume(T)

Assertional Constraints vs. Binding Constrains From: when nonvar(X)...From: when nonvar(X)... => when provable(X) … re-execution=> when provable(X) … re-execution => when a_fact(X)… more realistic=> when a_fact(X)… more realistic constraints on variable bindings are too fine-grained for distributed programming!constraints on variable bindings are too fine-grained for distributed programming!

Beyond Linda: Blackboard Constraint Operations wait_for(Pattern,Constraint): waits for a Pattern on the blackboard, such that Constraint holds, and when this happens, it removes the result of the match from the blackboardwait_for(Pattern,Constraint): waits for a Pattern on the blackboard, such that Constraint holds, and when this happens, it removes the result of the match from the blackboard notify_about(Pattern): notifies about this Pattern one of the blocked threads which waits for it with a matching constraintnotify_about(Pattern): notifies about this Pattern one of the blocked threads which waits for it with a matching constraint

Coordination with Blackboard Constraints Two threads: T1 (prod) and T2 (cons)Two threads: T1 (prod) and T2 (cons) ?-notify_about(stock_offer(aol,91)). %T1?-notify_about(stock_offer(aol,91)). %T1 ?-notify_about(stock_offer(aol,89)). %T1?-notify_about(stock_offer(aol,89)). %T1 % action triggered in T2 => Price=89% action triggered in T2 => Price=89 ?-wait_for(stock_offer(aol,Price), %T2 less(Price,90)).?-wait_for(stock_offer(aol,Price), %T2 less(Price,90)).

wait_for(Pattern,Constr) wait_for(P,C):- if(take_pattern(available_for(P),C), if(take_pattern(available_for(P),C), true, true, and(out(waiting_for(P,C)), and(out(waiting_for(P,C)), in(holds_for(P,C)) in(holds_for(P,C)) ) ). ) ).

notify_about(Pattern,Constr) notify_about(P):- if(take_pattern(waiting_for(P,C),C), if(take_pattern(waiting_for(P,C),C), out(holds_for(P,C)), out(holds_for(P,C)), out(available_for(P)) out(available_for(P)) ). ).

take_pattern/2 take_pattern(Pattern,Constraint):- all(Pattern,Ps), all(Pattern,Ps), member(Pattern,Ps), member(Pattern,Ps), Constraint, Constraint, cin(Pattern,_). % non-blocking in/1 cin(Pattern,_). % non-blocking in/1

The Reactive Agent Pattern sell(Who,Stock,AskPrice) :- notify_about(offer(Who,Stock,AskPrice)).sell(Who,Stock,AskPrice) :- notify_about(offer(Who,Stock,AskPrice)). buy(Who,Stock,SellingPrice) :- bg(try_to_buy(Who,Stock,SellingPrice)).buy(Who,Stock,SellingPrice) :- bg(try_to_buy(Who,Stock,SellingPrice)). try_to_buy(Me,Stock,LimitPrice) :- wait_for(offer(You,Stock,YourPrice), less(YourPrice,LimitPrice)),……….try_to_buy(Me,Stock,LimitPrice) :- wait_for(offer(You,Stock,YourPrice), less(YourPrice,LimitPrice)),……….

mobile threads with First Order AND-continuations a:-b,c,d.a:-b,c,d. binarization: a(C)::-b(c(d(C))).binarization: a(C)::-b(c(d(C))). get_cont(C,C)::-true(C). % binarizedget_cont(C,C)::-true(C). % binarized mobile threads algorithm:mobile threads algorithm: –move/0: get continuation, send over the net, resume execution on target –return/0: send back new continuation, resume execution back home

A Simple API for mobile threads run_server/0, here/0, there/0, where/1: => local or remote focusrun_server/0, here/0, there/0, where/1: => local or remote focus set_this_host/1, set_this_port/1, set_that_host/1,set_that_port/1set_this_host/1, set_this_port/1, set_that_host/1,set_that_port/1 move/0, return/0 vs. remote_run/1move/0, return/0 vs. remote_run/1 the(Pattern,Goal,Answer): runs Goal to produce the(Answer) or no => here/there switch =>local/remotethe(Pattern,Goal,Answer): runs Goal to produce the(Answer) or no => here/there switch =>local/remote

Examples of mobile threads Window 1: a mobile threadWindow 1: a mobile thread ?- there, move, println(on_server), member(X,[1,2,3]), return, println(back).?- there, move, println(on_server), member(X,[1,2,3]), return, println(back). Window 2: a serverWindow 2: a server ?- run_server.?- run_server.

mobile threads vs. RPCs: move once, compute many times ?-for(I,1,1000), remote_run(println(I)), eq(I,1000).?-for(I,1,1000), remote_run(println(I)), eq(I,1000). ?-there, move, for(I,1,1000), println(I), eq(I,1000).?-there, move, for(I,1,1000), println(I), eq(I,1000).

mobile threads: WHY? Large database, small agentLarge database, small agent Speed-up: move to a fast processor and back, transparentlySpeed-up: move to a fast processor and back, transparently here/there switch: same code can be run locally or remotelyhere/there switch: same code can be run locally or remotely fault tolerance - move->run->come backfault tolerance - move->run->come back

Emulating multiple answer computations ?- there, move, findall(X,for(I,1,3),Xs), return, member(X,Xs).?- there, move, findall(X,for(I,1,3),Xs), return, member(X,Xs). X=1;X=1; X=2;X=2; X=3X=3

A Classic Design Pattern, Publish/Subscribe: with mobile threads + Linda operations a reactive channel listener: in/1 loopa reactive channel listener: in/1 loop ?-listen(fun(_)).?-listen(fun(_)). selective channel publisher: out/1 loopselective channel publisher: out/1 loop ?-talk(fun(jokes)).?-talk(fun(jokes)). will not match:will not match: ?-talk(stocks(quotes,nasdaq))?-talk(stocks(quotes,nasdaq))

The (Pseudo) Server in The Client Pattern a client thread emulates server functionality (works behind a firewall!):a client thread emulates server functionality (works behind a firewall!): –pseudo_sever:- in(todo(X)),call(X),pseudo_server. –?- there,pseudo_server. the real client: there,out(todo(…))the real client: there,out(todo(…)) communication: through a blackboard on a (shared) real servercommunication: through a blackboard on a (shared) real server

The Octopus Agent Pattern branch out multiple Reactive Agent threads to various places using RPCs or mobile threadsbranch out multiple Reactive Agent threads to various places using RPCs or mobile threads watch for patterns containing returned results on the local blackboardwatch for patterns containing returned results on the local blackboard failure or non-termination of one thread have minimal effect: fault tolerancefailure or non-termination of one thread have minimal effect: fault tolerance

Designing Jinni Agent Classes Java layer:Java layer: –code and type inheritance –reaction to events –libraries: Java3D, XML, special devices etc. Prolog layer Prolog layer –knowledge processing –reaction to blackboard constraints –mobile threads

Design Patterns in Visual Jinni drives Java objects through handlesdrives Java objects through handles meta-programming is essentialmeta-programming is essential Java events interoperate with blackboard coordinationJava events interoperate with blackboard coordination easy extension to incorporate access to Java2D and Java3d librarieseasy extension to incorporate access to Java2D and Java3d libraries

jdialog/2: a Jinni Visual Component –jdialog(Q,A):- new_frame('Jinni Dialog',2,1,F), set_layout(F,border), new_label(F,Q,_),new_panel(F,flow,P), new_button(P,'Ok',out(bchoice(P,ok)),_), new_button(P,'Cancel', out(bchoice(P,cancel))), show(F), in(bchoice(P,A)), remove_all(F), destroy(F).

The Shared Virtual World Pattern set-up a registration mechanism for agents on serverset-up a registration mechanism for agents on server publish state changes to shared blackboard on server with out/1publish state changes to shared blackboard on server with out/1 one thread for each “ghost” (remote client) - too expensive!one thread for each “ghost” (remote client) - too expensive! => shared update loop: get each ghost’s state with in/1 from server and update=> shared update loop: get each ghost’s state with in/1 from server and update

Shared Virtual Reality Agents Web based: browser+EAI+Java+JinniWeb based: browser+EAI+Java+Jinni Jinni Server + Thin Jinni Applet ConnectorJinni Server + Thin Jinni Applet Connector NEXT: Java 3D virtual worlds connected in a peer-to-peer Jinni networkNEXT: Java 3D virtual worlds connected in a peer-to-peer Jinni network new transport layers: Corba, RMI, HLAnew transport layers: Corba, RMI, HLA

Stock Market Agents reactive agents, user defined rulesreactive agents, user defined rules Internet data mining for stock quotesInternet data mining for stock quotes expressiveness far beyond the usual limit/stop/market transactionsexpressiveness far beyond the usual limit/stop/market transactions Octopus Agent Pattern: wait for triggers on multiple stocks, analyst info, indexesOctopus Agent Pattern: wait for triggers on multiple stocks, analyst info, indexes

Educational Agents chat, self organizing groupschat, self organizing groups alerts triggered by blackboard constraintsalerts triggered by blackboard constraints reusable agent hierarchiesreusable agent hierarchies student progress evaluationstudent progress evaluation Wizard of Oz help desk: combined human and programmed agentsWizard of Oz help desk: combined human and programmed agents

Mutual Agent/Host Security: the BRING YOUR OWN WINE PRINCIPLE reflective meta-interpreter: a few lines of Prolog - can be mobile - bring your own!reflective meta-interpreter: a few lines of Prolog - can be mobile - bring your own! can act as a sandbox protecting the Host against the Agent -statically checkedcan act as a sandbox protecting the Host against the Agent -statically checked undecidability of a Turing equivalent meta-interpreter protects the Agent against the Hostundecidability of a Turing equivalent meta-interpreter protects the Agent against the Host

Conclusion expressiveness of LP + a few simple, orthogonal concepts: engines, threads, blackboards, mobile threadsexpressiveness of LP + a few simple, orthogonal concepts: engines, threads, blackboards, mobile threads design patterns: the need for an axiomatic reconstruction of the “programming style” itselfdesign patterns: the need for an axiomatic reconstruction of the “programming style” itself LP is ready for GUI-enabled, networked applications interoperating with mainstream software artifactsLP is ready for GUI-enabled, networked applications interoperating with mainstream software artifacts