Romanovsky 1996 Micro Processing and Micro Programming

8/9/2019 Romanovsky 1996 Micro Processing and Micro Programming

1/11

ELSEVIER

MicroprocessingandMicroprogrammingMicroprocessing and Microprogramming 41 ( 1996) 703-7 13

Application specific conversation schemes for ADA programsAlexander Romanovsky *

Applied Mathematics Department, State Technical University, 195251, St.Petersburg, RussiaReceived 10 October 1994; revised 10 January, 20 February 1995; accepted 12 May 1995

AbstractThe paper considers a development of the conversation scheme version proposed by A. Clematis and V. Gianuzzi in

Microprocessing ad Microprogramming (Vol. 32, No. l-5, 1991) [5] and Computer Languages (Vol. 18, No. 3, 1993) [6].The authors discussed the methodology of using conversations within a conventional concurrent language (Ada), whichmakes the conversation scheme practical. In our paper we concentrate on the improvements for their scheme. We believethat it is important for the programmer to have more choice, and propose what could be called a library of schemes fromwhich the appropriate scheme could be chosen depending on the application. We discuss ways of setting dynamically thenumber of processes participating in a conversation; of having different sets of servers involved in different alternates of thesame conversation; of introducing a global acceptance test which would be more sophisticated; of increasing robustness ofthe conversation. All of these proposals are meant to be used within a conventional language.Keywords: Software fault tolerance; Concurrent programming; Ada; Conversations; Clients/servers

1. IntroductionThe concept of the conversation [12] proved to be

basic for all research in the field of software faulttolerating for concurrent systems. Schemes relyingon this concept are intended to provide joint recov-ery of several processes exchanging information onthe basis of software diversity.

l Present address: Computing Department, University of New-castle upon Tyne, Newcastle upon Tyne, NE1 7RU, UK

Processes enter a conversation asynchronously; arecovery point is established in each of them. Theyfreely exchange information within the conversationbut cannot communicate with any outside process.When all processes participating in the conversationhave come to the end of the conversation, theiracceptance tests are to be checked. If all tests havebeen satisfied, the processes leave the conversation(thus, they can leave the conversation only at thesame time). Otherwise they restore their states fromthe recovery points. Should any process fail duringthe conversation execution, all the other processes

0165~6074/%/$15.00 0 1996 Elsevier Science B.V. All rights reservedSSDI 0165-6074(95)00014-3


2/11

704 A. Romanovsky/Microprocessing and Microprogramming 41 (1996) 703-713

are rolled back to their recovery points as well.Several alternates are to be implemented for eachprocess. A second alternate is attempted in eachprocess after the state restoration. We will use theterm conversation alternate to designate the execu-tion of these other alternates, one for each partici-pant. The conversation may be nested; in this case asubset of processes from the outmost conversationparticipate in it. To summarize, we can say that eachprocess participating in a conversation has severalalternative implementations of a part of its code andan acceptance test to check the result of an alternateexecution.

This general original concept was embodied andextended in several ways in later research (for differ-ent languages, different kinds of information ex-change, different potential application fields) [2,6-8,10,13]. In particular, the colloquy and dialogscheme [8] is an essential step forward in this re-search. A dialog is akin to a conversation alternate,and a colloquy is a set of successive executions ofdialogs. In this paper S. Gregory and J. Knightintroduce two levels of the acceptance test: localacceptance tests, one for each process-participant,and the global acceptance test, invoked only if all thelocal tests have been satisfied. This test checks aglobal invariant concerning the correctness of theentire dialog execution. Another important new fea-ture introduced in this paper is that different sets ofprocesses can participate in different dialogs.In their papers [5,6] A. Clematis and V. Gianuzzidiscussed a conversation scheme which allows toinvolve several servers and several clients in a con-versation and an appropriate methodology for struc-turing programs. We believe this to be a very impor-tant contribution because the paper considers theproblems of the conversation scheme design in thecontext of operation/procedure oriented languages[3] (mostly Ada), and this is quite important forimplementing the conversation scheme for object-based and object-oriented languages in general. Be-sides, we consider it an important advantage that this

scheme is intended for widely used industrial lan-guages and offers ways of using the conversationconcept within a language like these, without propos-ing to introduce new language constructs or modifyits run time system. Proposals of this kind can bequite interesting, but they have too little chance to beused in practice.

Our paper discusses improvements for the propos-als by A. Clematis and V. Gianuzzi. We do notintend this as a discussion of any flaws of thisscheme, but it seems that as their scheme is veryimportant, it is worth trying to improve it and to findseveral more flexible, more practical, less restrictiveschemes based on the original one. Other purposes ofour paper are to demonstrate how the existing gen-eral schemes [7-91 can be mapped onto a conven-tional strong typing industrial language, to discusschoices, problems and balance points of this map-ping and to give a set of particular practical ap-proaches for Ada programmers.

2. Analysing the scheme by Clematis and Gi-anuzzi2.1. The basic idea

The authors introduce a conversation manager tocontrol the execution of the conversation. Each con-versation has its manager. This manager receivesinformation about each process entering a conversa-tion and about the result of each local acceptance testchecking. Processes wait on the test line, where eachof them checks its local test, until all of them havereached it. Having obtained the results of all localtests, the manager decides whether to let processesleave the conversation (if all tests have been satis-fied) or, otherwise, make them start other alternates.Another responsibility of the manager is to involve(lock) all servers the participants will be workingwith during the conversation. It does this when thefirst process enters the conversation.


3/11

A. Rom anous ky / M icroprocessing and Mi croprogramm ing 41 (1996) 703-713 705

From the implementation point of view, this man-ager is an auxiliary Ada task; it has three entrieswhich can be called by processes taking part in theconversation (REQUEST to enter the conversation,

ACC_TEST to inform the manager about the result ofthe local test checking, and TEST-LINE to receive theresult of the global test checking). The structure ofthis manager is shown in Fig. 1.

task CONVERSATION MANAGER isentry REQUEST; -entry ACC_TEST (RESULT: in BOOLEAN);entry TEST LINE (RESULT: out BOOLEAN);end CONVERSA?%ON MANAGER;

task body CONVERSATION MANAGER ieNUM CLIENTS: con&ant :=n; -- # of clients in conversationtype NUM PROC CONV is range O..NUM CLIENTS;NUM ENT PROC:-NUM PROC CONV; -- # of clients entered conversationNUM-EX PROC: NUM-PROC-CON'.';- # of clients arrived at the test lineTES%?.:- BOO%&AN:zTRUE; -- 'and' of all local acceptance testsbegin

NUM EX PROC:=O;NUM-EN? PROC:=O;100; -

aelectaccept REQUEST doNUM ENT PROC:=NUM ENT PROC+l;if i&M ENT PROC=l-then

SlyENTER CONV;end if: -

. SM.ENTER_CONV;end REQUEST;

oraccept ACC_TEST (RESULT: in BOOLEAN) doNUM_EX_PROC:=NUM_EX_PROC+l;TESTS:=TESTS and RESULT;

end ACC TEST;-orwhen (NUM EX PROC=NUM CLIENTS) =>accept TEZT LINE (RESULT: out BOOLEAN) doNUM ENT Pi?OC:=NUM NT PROC-1;REScLT:=TESTS; - -if NUM ENT PROC=O then

S~.EXIT C~NV~TESTS); . SM.EXIT CONV(TESTS);NUM EX pROC:=O; -if not-TESTS then

NUM ENT PROC:=NUM CLIENTS;end if;- - -TESTS:=TRUE; -- ready for another attempt

end if;end TEST-LINE;

end aelect;end loop;

end CONVERSATION MANAGER;Fig. 1. The original conversation manager in [6].


4/11

706 A. Rom nnovsk y/M icroprocessing and Microprogramming 41 (1996) 703-713

Each process has a fixed structure whereby aftercall REQUEST the alternates are successively called.The result of the local test checking is passed to theconversation manager after each alternate execution.When some process calls REQUEST, all servers usedwithin the conversation are involved in it until theacceptance test has been satisfied. Each server has afixed structure as well; it can be involved in theconversation by entry ENTER_ CONV call and releasedby calling EXIT_CONV. If a local acceptance test hasnot been satisfied, entry EXIT_CONV is called as wellbut with value FALSE of the input parameter; in thiscase the server restores its saved state and remains inthe conversation.

One of the research purposes in [5,6] was to find ageneral template for the conversation scheme to beused in standard languages (like Ada), to simplifythe use of this template and to make this a clericaleasy job for programmers. We agree with the authorscompletely and share their intentions. We considerour proposals to be a natural next step and hope thatit can be more practical to have several templates ofthe conversation scheme, which can be used forimplementing different particular schemes dependingon the peculiarities of applications.2.2. The problems of the scheme

The number of participants has to be knownstatically, in advance; it is fixed and the same foreach alternate of the conversation. This is a restric-tive requirement for several reasons (see a detaileddiscussion in [9]>. It can be important to allowdifferent processes to enter a conversation (an alter-nate) with independent goals, to have different reac-tions to failure, independent algorithms, differentnumbers of alternates which a process is going to try,or allow the conversation to have different accep-tance tests for different alternates (perhaps, withdegradation). In an extreme case, fixing the numberof participants before the conversation (alternate)starts could lead to deadlock due to the deserter

process [lo] which can be produced by the failure ofa process to enter a conversation or to arrive at thetest line [9].

The set ofservers is the same for all alternates ofthe same conversation. This approach could decreasethe degree of concurrency in the system and increasethe danger of the capture effect [9]. It would bebetter to involve the set of servers required for eachalternate when this alternate is about to be started oreven when a real need in their services arises [13].This would allow to increase essentially the degreeof concurrency in the entire application system be-cause otherwise all servers which can be used in allalternates of a given conversation would have to belocked during successive execution of several alter-nates. The authors [6] mentioned this opportunity toimprove their scheme but we think it is worthwhileto discuss this thoroughly and to find approacheswhich would allow to cope with the mentionedproblems simultaneously.

The global test problem. The latest research [7,8]shows that it is not always sufficient or convenientfor programmers to check only the local acceptancetests (one in each process-participant). There mayarise a need for testing, in a more sophisticated way,the function of not only the local data of severalprocesses but also the data global for the conversa-tion [71. Another reason for the global acceptancetest is that it can be important to check the globalfunction (invariant) of the data of several processes.The scheme discussed seems to have low robust-ness and to lack control. What will happen if one ofthe processes does not enter the conversation? Whatcan happen if the client has not been implemented instrict accordance with the template proposed, and aprocess calls entry REQUEST twice? Is it possible thattwo different sets of processes should want to enterthe same conversation at the same time (which wouldcause a mess)? What will happen if one of theprocesses hangs while in a conversation? Most ofthese shortcomings should be accounted for by theAda strong typing and the will of the authors to


5/11

A. Romanovsky/ Microprocessing and Microprogramming 41 (1996) 703-713 707

implement a conversation scheme as transparent aspossible, with just a few additional conventions forprogrammers to follow. But it is obvious that leavingall these questions unanswered could be quite dan-gerous. The authors [6] consider pre-processing asthe only solution for these problems. We believe thatsince pre-processing has its own considerable disad-vantages, it is worthwhile to discuss templates, look-ing for those which are safer and more robust.

3. Improvements3.1. The number of participants

There are two ways of improving the initialscheme. Firstly, it can be done by dynamically set-ting the number of participants before or even duringthe execution of the first alternate.

Secondly, we could allow different numbers ofparticipants in different alternates. In this case wecan have a very soft and flexible scheme which isakin to the colloquy scheme [8]: a process can takepart in an alternate and afterwards decide not toparticipate in the next alternate (if the acceptance testhas not been satisfied). In Section 3.2 we will showhow some servers can be declared to be a set corre-sponding to a given alternate of the conversation,and that makes our proposal really similar to [8],where shared variables can be declared in each dia-log to serve as a means (additional to the rendez-vous) of process communication. The very importantdifference is that we do not require any changes inAda or its run-time system.

It seems important to enable the application sys-tem to decide dynamically how many participantsare going to participate in a conversation or analternate (say, the first process entering the conversa-tion will know this number). Thus, we need a lessrestrictive template.In terms of a particular implementation, that meansthat the conversation manager imposes the following

rules: entry NUMBER is to be called prior to the firstprocess entering any alternate. The number of partic-ipants in alternates can be different. To implementthis, we declare a new BOOLEAN variable IN_ALT andmake minor changes in the code of the conversationmanager. The new manager is given in Fig. 2.

With this manager, each process willing to partic-ipate in an alternate has to call entry REQUEST, unlikethe scheme in 161 n which a process calls this entrywhen entering a conversation.

It is clear that the two more flexible schemesbelow can be easily implemented on the basis of thisscheme.

In the first one, any number of processes canenter an alternate, and the conversation managerallows this until some process calls entry Acc_ras~,i.e. until it has checked its local acceptance test.After this event, the alternate is closed for entering,and all processes operating within the alternate willbe executed until their local tests have been checked.

In the second scheme, the alternate is closed fornew processes entering when the number of pro-cesses which called entry ACC_TEST is equal to thenumber of processes which entered the alternate. Thelatter scheme is quite similar to the colloquy scheme[8], the dialog being the counterpart of our alternate.3.2. Servers and t he set of servers

First of all, we want to discuss in what way aserver has to be changed to participate in an alter-nate. We believe that it is important to introduce aless restrictive necessary condition than that dis-cussed in [6]. It is the recoverability of the server.We say that the server is recoverable if in theinterface it has three procedures/entries ENTER, COM-MIT, ABORT (they correspond to the two entries dis-cussed) which provide the participation of the serverin an atomic action [4]. The server is involved in itby call ENTER; its result can be aborted by call ABORTor committed (COMMIT). If ABORT is called, then allmodification done during the atomic action is flushed.


6/11

708 A.Romanovsky/Microprocessing and Microprogramming 41 (1996) 703-713Note a very important peculiarity: unlike [6], we donot require that the server should be returned to thestate it was in before entering the conversation (alter-nate). This allows the server to participate in severalconcurrent conversations at the same time (obvi-ously, provided appropriate implementation supportsthis). The recoverability of the server can be ensuredin several ways; e.g. in the way proposed in thepaper [6] when a server is locked for processes notparticipating in the conversation, or by a transactionmechanism [ 111 with a concurrency control policy,or in some other way which takes into considerationthe peculiarities of application and of the use ofservers. The approach from [6] is a correct solutionbut, generally speaking, the methodology of using aserver should rely on its recoverability (which allowsto increase the parallelism of the system). Thus, weconsider each alternate to be an atomic action.

The next point we want to discuss is about allow-ing different sets of servers to be involved in differ-ent alternates of the same conversation. For example,a conversation can be designed in which processescommunicate through a buffer (which is imple-mented as an abstract data type) within the firstalternate, but in the second alternate they communi-cate through a stack. To offer this opportunity, wehave to implement each server with three parameter-less entries: ENTER_ LT, ABORT_ LT, COMMIT_LT,and in the body of the conversation manager theservers involved in each alternate have to be explic-itly enumerated by the designer. For example, themanager given in Fig. 3 allows different numbers ofprocesses and different sets of servers to take part indifferent alternates: (sl , . . . , sM) is the set of serversfor the first alternate. ' (Qk...,-.a, QN) is the set ofservers for the last one.3.3. The global test

We believe that it should be made possible todeclare an additional function, common for all partic-ipants, in order to check the global test. This can be

some global invariant relying on the results of theexecution of each participant. Two simple examples:it would be important to be able to check if a localvariable in one process is less than that in anotherone or compare the states of two servers by analysingthe results of two checking method calls. It is quitereasonable to expect that these kinds of invariantscan and should be checked after joint cooperativework of several participants in an alternate. Theseresults have to be accessible for this function, andthis can create a problem for the programmer [7].Note that the servers have to be aborted or commit-ted after the execution of the global test, and this canbe easily provided by the conversation manager pro-posed in [6,5] and improved in this paper.

From the implementation point of view, this func-tion should be put into the conversation managertask or into the package in which this manager isdeclared. This seems to be the most reasonablelocation for the global test corresponding to theentire conversation.3.4. Lack of control

There are two ways of providing additional con-trol for the scheme proposed. Firstly, some addi-tional conventions can be imposed to restrict and todiscipline the programmers. Secondly, an additionalcode can be introduced into the templates.First of all, it is possible to improve the robust-ness by controlling the names of all tasks entering aconversation (alternate). To do this, the manager hasto be implemented with a separate entry for eachtask (process), and instead of counting calls, theconversation manager would mark the tasks whichsuccessfully completed their alternates in the array ofBOOLEANlags.Besides, it is possible to introduce an additionalparameter the process name in each entry of theconversation manager. The type of this name can beeither predefined as INTEGER r, in a more sophisti-cated way, declared in the same package as theconversation manager was.


7/11

A. Romanovsky/Microprocessing and Microprogramming 41 (1996) 703-713

task CONVERSATION MANAGER isentry NUMBER (NfiB: n INTEGER);entry REQUEST;entry ACC_TEST (RESULT: in BOOLEAN);entry TEST-LINE (RESULT: out BOOLEAN);

end CONVERSATION MANAGER;tank body CONVERSATION MANAGER is

NUM_CLIENTS: INTEGER; -- # of clients participating in alternateNUM ENT PROC: INTEGER:=O; -- # of clients entered into alternateNUM-EX PROC: INTEGER: -- # of clients arrived at the test lineTESTS:- BOOLEAN:=TRUE;IN ALT: BOOLEAN:=FALSE; -- true when an alternate is startedFIRST: BOOLEAN:=TRUE; -- true if it is the first alternate

beginloop

selectwhen not IN ALT =>accept NUMBER (NMB: in INTEGER) do

NUM CLIENTS:=NMB;IN ALT:=TRuE;NUM EX PROC:=O;

end NUMBER;01

when IN ALT =>accept REQUEST do

NUM ENT PROC:=NUM ENT PROCtl;if %lM ENT PROC=l-and-FIRST then

SI.ENTER co~v;- . . . SM.ENTER_CONV;end if;end REQUEST;

01

when IN ALT =>accept ACC TEST (RESULT: in BOOLEAN) doNUM EX PEOC:= NUM EX PROCtl;TESTS:= TESTS and-RESULT;

end ACC TEST;Orwhen (NUM_EX_PROC=NUM_CLIENTS) and IN_ALT =>

accept TEST-LINE (RESULT: out BOOLEAN) doNUM ENT PROC:=NUM ENT PROC-1;RESiLT:=TESTS; - -if NUM_ENT PROC=O thenSl.EXIT CONV(TESTS);

NUM EX PROC:=O;. . . . SM. EXIT_CONV(TESTS);

FIRST:= TESTS; -- false for the next alternate-- true for the next conversation

TESTS:=TRUE;IN ALT:=FALSE;

end if:end TEST LINE;

end select;end loop;end CONVERSATION MANAGER;_

Fig. 2. The conversation manager allowing different numbers of processes to take part in different alternates.

709


8/11

710 A. Romanousky/Microprocessing and Microprogramming 41 (1996) 703-713

task body CONVERSATION_MANAGER isMAX ALT: constant:= k; -- # of the alternates in conversationt& CONV ALT ia range 1 . . MAX_ALT;NUM CLIENTS: INTEGER; -- # of clients participating in the alternateNub-ENT PROC:INTEGER:=O; -- # of clients entered into alternateNUM-EX PROC: INTEGER: -- # of clients arrived at the test lineALTNUM: CONV ALT; -- number of the current alternateTESTS: BOOL&I'I:=TRUE;IN ALT: BOOLEAN:=FALSE;

be&ALT NUM:=l;100;select

when not IN ALT =>accept NUMBER (NMB: in INTEGER) doNUM CLIENTS:=NMB;IN ALT:=TRUE;NUM EX PROC:=O;

end lii!MBER;when IN ALT =>accept REQUEST doNUM ENT PROC:=NUM ENT PROC+l;

if GUM ENT PROC=l-then- -case ALT NUM iawhen l-=> Sl.ENTER_ALT; . . . SM.ENTER_ALT;. . .when MAX ALT => Ql.ENTER_ALT; . . . QN.ENTER_ALT:-end cam;

end if;end REQUEST:

OZ when IN_ALT =>accept ACC_TEST (RESULT: in BOOLEAN) do

NUM EX PROC:= NUM EX PROC+l;TESTS:; TESTS and-RESULT;

end ACC TEST;-OXwhen (NUM EX PROC=NUM CLIENTS) and IN ALT =>

accept TEST LINE (RESULT: out BOOLE%J doNUM ENT PgOC:=NUM ENT PROC-1;RESi!LT:'TESTS; - -if NUM_ENT_PROC=O then

if not TESTS thencam ALT NUM is

when I-=> Sl.ABORT ALT; . . . SM.ABORT_ALTi_. . .when MAX_ALT => Ql.ABORT_ALT; . . . QN.ABORT_ALT;

end case;ALT NUM:=ALT NUM+l;

else - -

case ALT NUM iawhen l=> Sl.COMMIT ALT; . ..i SM.COMMIT_ALT;-. . .when MAX_ALT => Ql.COMMIT_ALTi . ..i QN.COMMIT_ALTi

end case;ALT NUM:=l;

end ir;TESTS:=TRUE;


9/11

A. Romanovsky/Microprocessing and Microprogramming 41 (1996) 703-713 711

IN ALT:=FALSE;end if;end TEST LINE;

end select;end loop;

end CONVERSATION MANAGER;-Fig. 3 (continued).

More control can be provided if the conversationmanager knows the names of processes (Ada tasknames) participating in the conversation. In this casethe conversation manager can use the deadline mech-anism to detect that there is something wrong with aprocess and to abort it.We believe it is dangerous that any process notparticipating in the conversation can call any entry(except the two service ones) of any server in anuncontrolled way. This means that any process canfreely manipulate a server involved in a conversa-tion. This can undermine the consistency of serverdata and cause information smuggling. Introducing anew parameter for each server entry call could be asolution in this case. This parameter is the name ofthe conversation and can be checked: if a servermethod call is not within the active conversation ornot within any conversation at all, the call is re-jected, and the return code informs the client aboutthis.This makes implementation more complex,though, particularly in a language in which parame-ters cannot be evaluated in the entry operation (Ada).The authors [6] addressed a similar problem withrespect to conversation nesting. Within Ada, thesolution can lie in implementing an additional proce-dure which is to be the first operation to be called ineach server method. This procedure would check the

rights of the client (with the conversation name as aninput parameter).

Making the conversation manager more complexcan allow to change the direction of the rendezvousin calls ACC_TEST and TEST_LINE. Knowing thenames of conversation participants, the managerwould be able to call these entries; then the appropri-ate Ada exception TASKING_ ERROR can inform itabout errors which occurred within a particular pro-cess during the execution of an alternate or a conver-sation.The conversation manager, each server and eachclient have to handle all exceptions which can beraised during its work. At worst, a catch-all handlerhas to be added to each template of the scheme [6]. Itcan be very dangerous to provide a recovery schemewhich would hang forever in case of any exceptionraised (because exceptions in Ada are not propagatedbeyond the task in which they were raised). Theproper reaction to this should be rejecting the currentalternate with a subsequent attempt to execute thenext one.

The deadline mechanism has proved to be of highimportance for the practical use of conversationschemes [2,7,8]. Ada has a feature (timed entry call)which allows to impose a timeout on the executionof processes taking part in a conversation (in analternate). The conversation manager can be im-


10/11

712 A. Rom anow ky /Microprocessing and Microprogramming 41 (1996) 703-713

proved to guarantee a restricted time of executingeither each alternate or the entire conversation. Pos-sible reactions to the timeout exhaustion can be:raising a predefined exception, deleting all processes.Though these solutions could be considered drastic,we believe that, first, time exhaustion should beinterpreted as a sign of incorrect behaviour of pro-cesses (unhandled exception, deadlocks, etc.) whichthey are not able to cope with by themselves and,secondly, in any case it is better to know that there issomething wrong with processes and to be able toreact.

The authors [6] believe that a certain pre-processorcan help to avoid the problems discussed. It is onlytrue for some of them (but if, for instance, anexception is raised in a task, it will not be handled,and this task will be suspended forever). The imple-mentation of a tool like this for Ada is a verydifficult problem, not only because of separate com-pilation or strong typing, but because the use of newlanguage constructs is a serious barrier to employingany other engineering tools intended for a standardlanguage (CASE, debugger, syntax editor, etc.). Analternative solution could be implementing a checkerto find all violations in using the templates proposed.In any case, we believe that extending the templatesto increase their robustness is vital.

4. Future researchAs Ada is a strongly typed language, it is virtually

impossible to give users a completely transparentand unified way of using conversations. The mainreasons are as follows: it is impossible to pass a taskname as a parameter for an entry call, it is prohibitedto have a unified data structure keeping pointers totasks of several different types and to call entries ofthese tasks. As a result, it is impossible to createdynamically a list of the conversation participantsand to implement a manager controlling any (or all)conversation(s). For each conversation a specific

manager has to be implemented which has to knowsome information about all participants: the numberof processes, the names of servers. The approachproposed facilitates this implementation by offeringseveral templates.

Implementing a unified conversation manager as aclass seems to be one worthy purpose for futureresearch (particularly in concurrent object orientedlanguages). With this class, a conversation managerobject can be created for each particular conversa-tion.

Another very reasonable direction of researchconcerns Ada9X [l]. This language has very impor-tant features which can simplify the implementationof the conversation scheme and, besides, thanks tothe upward compatibility with Ada, all proposalsdiscussed can be used in it directly. Among the newfeatures worth mentioning are those allowing to fa-cilitate the deadline mechanism by using more elabo-rate statements select and delay.

One more purpose of research could be imple-menting a conversation manager which would con-trol the execution of all conversations. Ada9X allowsto have a procedure name as an access type, so it ispossible to have one unified manager which wouldkeep the tree of all active conversations (includingthe nested ones) and the list of declared conversa-tions. When a conversation is declared, a new nodeis created in this list. It keeps the conversation name,the number of participants and the names of the threeprocedures (see Section 3.2) which work with serversrequired for a given alternate (for each alternate ofthe conversation). These three procedures for the i-thalternate could be:

- SERVERS_ ENTER_ ALTi t0 Call entries ENTER_ ALTin all servers of the ith alternate;

- SERVERS_ ABORT_ ALTi t0 Call entries ABORT_ ALTfor all servers;

- SERVERS_COMMtT_ALTi t0 Call entriesCOMMtT_ALT for all servers.


11/11

A. Ro man ov sky /Mi croprocessing and Mi croprogramm ing 41 (1996) 703-713 713

5. SummaryThe paper discusses our improvements to the

conversation scheme proposed by A. Clematis andV. Gianuzzi. We have demonstrated several schemes,each of which could find its own field of application.We believe that it is important for users to havechoice and that, within the proposals discussed, it ispossible to find a scheme which is safer, moreflexible, less restrictive, more dynamic, more faulttolerant or allows more parallelism, than the originalone. We have not been able to offer templates for allof our proposals, but we hope that discussing themcould help to find the most appropriate conversationscheme for each particular application which re-quires a joint recovery of several processes.

AcknowledgementThis work was supported by the Royal Society,

UK, and by funding from the ESPRIT Basic Re-search Action entitled Predictable DependableComputing Systems. The author is grateful to A.Clematis, V. Gianuzzi and the anonymous reviewersfor their suggestions.

Referencest11

01[31

[41

Ada programming language, Language and standard li-braries, Draft. Version 4.0, ANSI/ISO/IEC, IR-MA-1363-3,1993.T. Anderson and J.C. Knight, A framework for softwarefault-tolerance in real-time systems, IEEE Trans. Sojiw areEng. SE-9(3) (1983) 355-364.G.R. Andrews and F.B. Schneider, Concepts and notationsfor concurrent programming, ACM Compur. Surveys 15(1983) 3-44.A. Best and B. Randell, A formal model of atomicity inasynchronous systems, Acta Inform. 16 (1981) 93-124.

[ 5 1

[61

[ 7 1

[81

[ 9 1

A. Clematis and V. Gianuzzi, Software fault tolerance inconcurrent Ada programs, Mi croprocessing and Mi cropro-gramm ing 32 (l-5) (1991) 365-372.A. Clematis and V. Gianuzzi, Structuring conversation inoperation/procedure oriented programming languages, Com-put. Lang. 18 (3)(1993) 153-168.F. Di Giandomenico and L. Strigini, Implementations andExtensions of the Conversation Concept, Proc. 5th Inr. GI/ITG / GMA Conf. on Fault-Tolerant Comput ing Sysiems-Tests, Diagnosis, Fault Treafmenr, Nhmberg, Germany(1991) 42-53.ST. Gregory and J.C. Knight, A new linguistic approach tobackward error recovery, Proc. 15th Inr. Sym p. on Fault -Tolerant Computing, Ann Arbor, Michigan (1985) 404-409.S.T. Gregory and J.C. Knight, On the provision of backwarderror recovery in production programming languages, Proc.19th Int. Symp. on Fault-T olerant Comput ing, Chicago, Illi-nois ( 1989) 507-5 11.

[lo] K.H. Kim, Approaches to mechanization of the conversationscheme based on monitors, IEEE Trans. So&are Eng. SE-8(3) (1982) 189-197.

[l l] N.A. Lynch, M. Menit, W.E. Wehil and A. Fekete, A?omicTransactions (Morgan Kaufmann, 1993).

[12] B. Randell, System structure for software fault tolerance,IEEE Trans. SofhYare Eng. SE-l (2) (1975) 220-232.

[13] L. Strigini and F. Di Giandomenico, Flexible schemes forapplication-level fault tolerance, Proc. 10th Symp. on Reli-able Disrribufed Systems, Pisa, Italy (1991) 86-95.

Alexander B. Romanovsky received theMS degree in Applied Mathematics fromMoscow State University in 1976 andthe PhD degree in Comouter Sciencefrom St. Pet&burg State T&hnical Uni-versity in 1988. In 1991 he worked as avisiting researcher at Computer Archi-tecture Lab ABB Ltd Research Center,Switzerland. In 1993 he was a visitingresearcher at Istituto di Elaborazionedella Informazione, CNR, Pisa, Italy. In1994 he was a post-doctoral fellow atthe Computing Department, Universityof Newcastle upon Tyne. His permanent position is of a seniorlecturer at the Applied Mathematics Department, St. PetersburgState Technical University, Russia. His research interests includefault tolerance, software diversity, concurrent programming, con-current object oriented and object based languages.

Romanovsky 1996 Micro Processing and Micro Programming

Documents

Transcript of Romanovsky 1996 Micro Processing and Micro Programming