2 Addressing the Inheritance Anomaly One of the major issues in correctly connecting task communication mechanisms and the object-oriented paradigm is

Transcription

1 Extendable, Dispatchable Task Communication Mechanisms Stephen Michell Maurya Software 29 Maurya Court Ottawa Ontario, Canada K1G 5S3 Kristina Lundqvist Dept. of Computer Systems Uppsala University, P.O. Box Uppsala, Sweden January 14, 1999 Abstract The addition of object-oriented features to Ada has left a disconnection between the object-oriented paradigm and the intertask communication and synchronisation paradigms. The lack of extensibility of tasks and protected types as well as the task synchronisation inheritance anomaly has made design of systems that use them with object oriented features more dicult. This paper proposes Ada language changes that would make protected types and tasks partners in object oriented programming and would cure the inheritance anomaly. 1 Introduction During the Ada9X revision process, a new program element called protected types was designed to manage asynchronous intertask communication [ARM95]. Consideration was given at that time to make protected types object oriented, but a conscious decision was made not to do this. The reasons at the time were that the realtime community was quite nervous about the new object-oriented paradigm and how Ada9X would implement it, and whether or not it would interfere with the tasking paradigm. In the 4 years since the Ada9X project nished the language denition, some realtime developers have expressed dissatisfaction with the disconnect between Ada95's object-oriented paradigm and the non-oriented task communication features in the rendezvous and in protected objects. A number of papers about Ada95's lack of support for inheritance and dispatching in the task communication mechanisms have appeared, [MW96] [WMB96] [SN98] the most recent being a proposal by O.P. Kiddle and A.J. Wellings at SIGAda98 [KW98] to extend the object oriented paradigm to extensible protected types. We propose a modied approach to the Kiddle and Wellings approach to extendable tasking communication mechanisms which use protected objects as the controlling operand for dispatching operations. Instead, we propose a technique that relies upon the controlling type of task types and protected types as expressed by discriminants to eect the extensibility of these Ada types. We also address mechanisms to create object-oriented task communication mechanisms. Once the need for extensible task communication facilities has been established by the Ada community, and the syntax and semantics of the constructs agreed upon, we believe that a complete proposal can be developed for consideration by ISO/IEC/JTC1/SC22/WG9 for inclusion in a future language revision.

2 2 Addressing the Inheritance Anomaly One of the major issues in correctly connecting task communication mechanisms and the object-oriented paradigm is the avoidance of the tasking inheritance anomaly. As [MY93] and [LW94] discuss, this anomaly occurs, not because tasks and protected types aren't extensible or tagged, but because the synchronisation conditions (entry barrier conditions and task entry guard conditions) cannot be updated to take into account new algorithms needed when the data being manipulated by these types is extended. Ada's entry barrier expressions (for protected types) and entry guard conditions (for tasks) already give a signicant amount of expressive power in writing synchronisation code. Message types can be individually handled with dedicated synchronisation code by giving each message type its own entry. The missing functionality from the language is the ability to add new synchronisation conditions and entry code to existing task types and protected types. Our proposal will solve the inheritance anomaly by permitting the addition of new entry barrier/guard conditions and overridden entry code when the protected type or task is extended. 3 Adding Capabilities to Ada For projects developing object-oriented systems that communicate via Ada task synchronisation mechanisms, there is a clear need to extend the object-oriented paradigm to communicating concurrent processes to permit extensibility to add new communication routines and update task synchronisation algorithms without having to rewrite functioning subsystems. Certainly the capability to extend the tasking paradigm, add new locking algorithms and add new task interactions without recoding the old algorithms adds powerful new paradigms to the language. The last four years has shown that the Ada OO facility is ecient and safe, and many realtime communities are using the OO paradigm with some version of concurrency (either Ada tasking or some other form of tasking). Certainly the protected type paradigm is a valid candidate for modication. Kiddle and Wellings have presented an approach to the creation of this paradigm. Our belief is that the basic analysis and proposed capability is sound and should be considered by the Ada community for inclusion in Ada2005. There are, however, a number of issues with their approach that need to be addressed. The ones that we have identied are discussed in Annex A. Kiddle and Wellings argue for the extension of the Protected Type paradigm, but do not seriously consider the task/rendezvous mechanism. There are some who feel that this mechanism is obsolete now that PTs are in the language. The Ada task/rendezvous capability, however, is a stand-alone synchronous communication paradigm which will be used by many development teams. If these teams also use OO techniques, then the task and rendezvous mechanisms are valid candidates for modication. Annex B addresses some of the issues related to integrating Ada tasks to the OO paradigm. 4 Conclusions If the ISO/IEC/JTC1/SC22/WG9/ARG is to actively consider proposals to integrate Ada tasking constructs with the object-oriented paradigm, then a clear statement of the need and a viable proposal are required - probably sometime in The 9th IRTAW could be instrumental in this process. To be eective, a number of developed proposals are needed, and the IRTAW needs to carefully evaluate the 2

3 perceived requirement and proposed solutions to determine the feasibility of the proposed approaches and to make clear recommendations to ISO/IEC/JTC1/SC22/WG9 on an approach that would be acceptable to the realtime Ada community. We believe that an approach based upon the work of Kiddle and Wellings and the proposals presented here would form a good start for such a proposal. A Protected Types and OO O.P. Kiddle and A.J. Wellings [KW98] make a strong case for the extension of Ada's Protected Type mechanism to eliminate the tasking inheritance anomaly. After a fairly extensive analysis, [KW98] propose an extendable, dispatchable protected type mechanism which consists of the following: Adding the optional keyword \tagged" to protected types. Such types would be extensible in the sense that new data elements can be added to the data in the private area, protected functions, protected procedures and protected entries can be overridden and new ones can be added. New guard conditions can be added to overridden entries. New primitive subprograms external to the protected type can be added. Protected subprograms and protected entries are dispatching when called using a class-wide protected type. This proposal is a good start in addressing the issues and proposing an extensibility mechanism for Ada protected types. There are, however, a number of additional issues that must be considered for tagged protected types to be seriously considered by the Ada community. A.1 Basic Mechanism The proposal to add protected type extensibility to the language, the restriction to types only (excluding singular protected objects) and the basic proposals for its behaviour and primitive subprograms is reasonable. The major diculty with the proposal is the proposal that the protected type be made the controlling operand for dispatching subprograms. Protected types are often used to operate on data, and in an object-oriented language on classes of data. When one adds new descendants to a class which are served by a protected type, it should be possible to extend the protected type by adding data elements to the protected type itself, adding or overriding protected operations, and by modifying the entry barrier to handle new conditions. There are two ways in which such a protected type could be extended over tagged types: when an extensible protected type is declared in the same scope as the tagged type it becomes \primitive" to the type in the same way that normal subprograms are primitive on the type; or when a tagged type is made a discriminant of a protected type, it becomes a controlling operand, and the protected type can be extended by adding data elements, adding or overriding protected operations, and by modifying protected entry barrier conditions. Of the two methods, we prefer the second since protected types with the desired behaviour would not be required to be declared in the same scope as the 3

4 controlling types. It is even possible that a protected type with multiple tagged discriminants could have dispatching protected operations on types from dierent classes, although any single protected operation could only have a single controlling operand. Figure 1 shows an example of the denition of such an extensible protected type denition. with MH_Pkg; -- contains tagged type Message_T protected type Message_Handler_T( M : MH_Pkg.Message_T ) is tagged entry Put( M : in MH_Pkg.Message_T ); -- dispatching on M entry Get( M : out MH_Pkg.Message_T ); -- dispatching on M private M_Queue : array( Some_Range ) of MH_Pkg.Message_T; First, Last : Some_Range; entry Put( M : in MH_Pkg.Message_T ) when Cond_1; -- barrier entry Get( M : out MH_Pkg.Message_T ) when Cond_2; -- conditions end Message_Handler_T; Figure 1: Example Specication of an Extensible Protected Type. This proposal diers from the Kiddle-Wellings approach in that there is no notion of the protected type being the controlling parameter in calls, and there is no notion that subprograms declared in the same scope being primitive on the protected type. It would seem reasonable that the visibility of protected type private parts and the extensibility of protected types should be limited to extensions within the same declarative region, subunits or child packages. A.2 Separation of Specication and Body The proposal described in [KW98] would have barrier evaluation happening in a way that could make protected type bodies dependent on the bodies of other protected types. It is a fundamental principle in Ada that there be no dependency between the body of a unit and the specication or bodies of dependent units. In fact, one of the major accomplishments of Ada95 was the removal of the Ada83 dependency between the body of a generic unit and the units which instantiate the generic. Any proposal to add or extend barrier conditions must nd a way to permit extension without having dependency upon the body of the ancestor unit. Since the data elements of Ada95 Protected Types are contained in the specication private part, there are no protected body dependency issues for data extensions. There is, however, a dependency issue with respect to barrier expressions contained in the body of the protected type. To remove this dependency, we propose to move the barrier condition expressions from the body of the protected type to the private part of the specication. The syntax of the protected type specication is shown in Figure 1. Barrier conditions would be replicated in the protected type body but must statically match those given in the specication. With this proposal, the entry and the associated entry barrier condition are placed in the private part of the specication. This mechanism lets the condition be visible and known to extensions of the type, which should also make it possible to completely replace the barrier condition, not merely \strengthen" the condition as proposed in [KW98]. 4

5 A.3 Redispatching of Protected Subprograms The extension to protected subprograms following our proposal is straightforward since it exactly follows the syntax for redispatching of normal subprograms, that is to say, a subprogram dispatches on a class-wide controlling formal parameter, i.e. one that is a standard Ada tagged type. Since the protected subprogram already has the lock for the protected object, the locking issues exactly match existing protected type syntax/semantics. This is an improvement on the Kiddle-Wellings approach which conicts with Ada's use of the type name to designated the current object within the type. A.4 Redispatching to Protected Entries The redispatch to protected entries in an ancestor type raises a number of issues that are not present for protected subprograms. Because entries are potentially blocking operations, calls to protected entries, even in the same protected object, are not allowed in Ada95. This is a cornerstone of Ada95 protected entry semantics which, in our opinion, would be unacceptable to the realtime community to change. Therefore, the only form of redispatching which should occur is direct calls to dispatching protected subprograms or requeue to overridden entries as discussed below. A.5 Requeue A major issue for the implementation of object-oriented protected types is that every new entry that overrides those of ancestors creates a new queue in every protected object of the new type. This provides the opportunity for any caller to call the protected object's entry queue as any ancestor. Similarly, a caller can be requeued to any queue after a type conversion to the appropriate ancestor. The requeue mechanism does not require an immediate acceptance by the protected-object-asancestor, so there is no need for the barrier conditions to be true. This exibility permits signicant modications to the entry locking protocols when a protected type is extended, which should provide signicant capability to the feature. The mechanism for the requeue operation is shown in Figure 2. requeue PT.Entry_Id( Ultimate_Ancestor(T(Var))'Class, ); -- for a class-wide dispatching call, or requeue PT.Entry_Id( T(Var), ); -- for an explicit call -- where Var is an object of a class-wide type with a tag that -- matches the current instance for the entry, T(Var) is an -- explicit type conversion to an ancestor Figure 2: Example of Dispatching Requeues. A.6 Protected Type Summary This proposal provides a mechanism for object-oriented protected types which can be parameterised and extended over tagged types passed as discriminants. We believe that these proposals solve the inheritance anomaly for Ada95 and permit Ada protected type task communication mechanisms to be fully integrated with the other object-oriented features. 5

6 B Extensible Tasks The original task communication and synchronisation method dened by Ada was the task rendezvous. The rendezvous mechanisms are completely synchronous and provide powerful paradigms to provide sequencing, scheduling preference control, and expose state transition behaviour in the body of server tasks. The lack of a smooth connection between tasks and Ada's tagged types, however, forces developers to use overly complex workarounds to solve the extension and inheritance anomalies. There are some fundamental issues that make the extension of tasks more challenging than does the extension of protected objects. Tasks have only entries, which in our proposal are not redispatching (but can be dispatched upon requeue), have most of the declarations in the body, and can accept the same entry more than once in the same select statement or in dierent select statements. In order to make tasks extensible, the Ada community would have to accept syntax and semantic changes that moved specications to the task specication part and signicantly restricted what could be done within a task body. This proposal outlines the basic syntax changes needed to make tasks and the rendezvous extensible, in the hope that the realtime community will think about the issues, decide if it is worthwhile persuing such changes, and decide what limitations would be acceptable to obtain extensible tasks. B.1 Basic Mechanism All of the issues about the inheritance, visibility and primitive operations of protected types discussed in Annex A for Protected Types and in [KW98] also apply to Ada task types, with 1 major exception - the declarative region of a task (except for the name and entry specication) is in the body of the task. The discussions of the previous section about the separation of specication and body apply equally to tasks: - to extend the data objects of a task, they must be declared in the task specication, which represents a fundamental shift in Ada syntax. The other fundamental issue for extensible tasks is in normal Ada tasking, entry guards and the \select" code that examines these guards all must occur in-line within the task body, and can be replicated, nested, or occur in several \select" blocks within the task body code. To move the guard condition and the entry executed into the specication, it must be known that extensible tasks are restricted as follows: only 1 select statement within a single loop; and each entry can only be selected once within the select statement. An example denition of an extensible task is shown in Figure 3. With this proposal, data elements specied in the task specication part can be added and entry guard conditions provided in the private specication can be overridden. This is shown in Figure 4. In the extensible tasking proposal, it should be noted that Conditions in the body, and the entry called must statically match the denition given in the specication. The opportunity exists to change the guard conditions, as well as replacing the entry code at each level. B.2 Dispatching to Ancestor's Entry There are two possible mechanisms to eect redispatching within the tasking/rendezvous proposal. The rst mechanism is for the body of the task executing the rendezvous 6

7 with Pkg; -- containing Some_Tagged_Type task type T( V : Pkg.Some_Tagged_Type) is tagged Entry E1( X : Pkg.Some_Tagged_Type; Y : Y_Type ); Entry E2( W : Pkg.Some_Tagged_Type; Z : Z_Type); private Entry Ep1(); XL : X_Type; YL : Y_Type; when <cond1> => accept E1(); when <cond2> => accept E2(); when <cond_p1> => accept EP1(); end T; task body T is -- more declarations begin -- T while <cond> loop select when <cond1> => accept E1() do end E1; when <cond2> => accept E2() do end E2; end select; -- other processing end loop; end T; Figure 3: Tagged Task Specication and Body. 7

8 task type T1(V : Pkg2.Some_Tagged_Type_2) is new T with -- Note that we are extending T with a new entry E_New, -- overriding E1, and adding new data elements and -- conditions on the select statement. entry E_New( K : Pkg2.Some_Tagged_Type_2 ); Entry E1( X : Pkg.Some_Tagged_Type; Y : Y_Type ); private entry E_Private_New( K : Pkg.Some_Tagged_Type ); K1 : K_Type; when <condn1> => accept E1(); when <condnn> => accept E_New(); end T; task body T1 is -- more new declarations begin -- T while <cond> loop -- Since this task body extends the body of T, only the -- new or overridden entries need to be defined. select when <condn1> => accept E1() do end E1; when <condnn> => accept E_New() do end E_New; end select; -- X No other processing allowed XXX end loop; end T; Figure 4: Task Extension and Extension Body. 8

9 to do a type conversion to a parent type and call it's parent's type entry as a classwide call. In Ada, however, it is erroneous to call one's own entries, hence, just as in the case of protected entries, redispatching via the entry call mechanism does not make sense. The second mechanism is the requeue. The requeue mechanism would have the identical semantics to the dispatching requeue mechanism discussed for protected entries. In our proposal the requeue semantics are identical to those presented in Annex A for protected types, and hence will not be discussed further here. B.3 Extensible Task Conclusion Although most of the work in the Ada community with respect to extensible tasking mechanisms has been directed to the protected type mechanism, the task communication mechanisms should be seriously considered for inclusion in this process. In order to make the rendezvous extensible in the object-oriented sense, some of the specication syntax that is currently in task bodies must be moved to the task specication private part. In addition, restrictions on the way that the select statement and accept statement are used must be specied and become part of the language for tagged task types. With these modest changes, it should be possible to also consider task rendezvous as an extensible task communication paradigm that satises the tasking inheritance anomaly. References [ARM95] Intermetrics, \Ada95 Reference Manual", ISO/IEC-8652:1995, [GS83] G. Andrews and F. Schneider, \Concepts and Notations for Programming", ACM Computing Surveys 15(1), [KW98] O.P. Kiddle and A.J. Wellings, \Extensible Protected Types", Proceedings of the ACM SIGAda Annual International Conference, [LW94] B. Liskov and J. Wing, \A behavioural notion of subtyping", ACM Transactions on Programming Languages and Systems 16(6), [MW96] S.E. Mitchell and A.J. Wellings, \Synchronization, Concurrent Object- Oriented Programming and the Inheritance Anomaly", Computer Languages 22(1), [MY93] S. Matsouka and A. Yonezwa, \Analysis of Inheritance Anomaly in Object- Oriented Concurrent Programming Languages", Research Directions in Concurrent Object-Oriented Programming, MIT Press, [SN98] G. Schumacher, and W. Nebel, \How to Avoid the Inheritance Anomaly in Ada", in proc. Reliable Software Technologies - Ada-Europe'98, LNCS 1411, [WMB96] A.J. Wellings, S. Mitchell, A. Burns, \Object-Oriented Programming with Protected Types in Ada95", International Journal of Mini and Micro Computers 18(3),