Friday, February 06, 2009

Z++ task type

The notion of type seems too complex to be accepted as a primitive, say like the notion of point in Euclidean geometry. The reality is that, type is only relatively complex and as such it is no more complex than point.

There are some similarities between the notion of type and other concepts. For instance, we define physical units in terms of a few selected ones, as in defining speed in terms of distance (length) and time. Similarly, we define new types in terms of a few pre-defined types. This similarity is only partial but a good basis for taking the notion of type as undefined.

Attempting to define the notion of type by identifying it as a set of literals and a set of methods does not take us anywhere either. Indeed, there are other concepts unique to automation (programming) that are used in defining new types. For instance, an instance of a Z++ task is created in a new thread. In this article we will also discuss the notions of task idler and task signal handlers. It therefore seems reasonable to accept the notion of type as a primitive concept of automation the same way that point is to geometry.

We shall refer to the mechanism used for defining new types as a type constructor. For instance class is a type constructor because it is a mechanism for telling a compiler how to create new instances of the type. Note that defining new types is apart from defining the notion of type itself. Useful and well-tested type construction mechanisms are indispensable for creating reliable software because the testing and verification of correctness of the complexity in creating and manipulating instances of a type is localized to the implementation of a compiler.

Task is a type constructor like class. Indeed, like Z++ class, tasks can have invariants and method constraints, and follow the same inheritance rules. Furthermore, task templates are defined exactly the same way as class templates are.

However, an instance of a task is endowed with its own thread. The creation and destruction of the thread associated with a task object is transparent. Moreover, when a task is derived from other tasks, or includes members that are of task type, each task base or task member is endowed with its own thread. Thus, one declaration may create a multi-threaded object, entirely transparent to user program.

A Z++ task object has a queue for responding to calls to its public methods. This means two things. First, a task object invokes one of its public methods at a time, in the order in which the requests arrived in its queue. Second, each time a task object receives its time slice, and if not busy executing a method, it checks its queue for new incoming requests.

When a task object finds its queue empty, instead of using its time slice in idle mode it passes control to the Z47 Processor so another thread can run. In Z++ it is possible to tell the task object to do something via its idler method instead of giving up its time slice. A task idler is a private method that cannot be called directly. The task object invokes its idler automatically. The notion of idler is useful for period checks, updates and other chores.

A task signal handler is a private method of a task object that is automatically invoked when its corresponding signal is generated. This provides a simple mechanism for responding to events. A task can have any number of signal handlers, but each handler must correspond to exactly one signal.

It is not hard to see that task type constructor hides a great deal of complexity behind its simple defining mechanism. Incidentally, the whole idea of research in automation is to cover useful complexity under the blanket of simplicity without loss of generality. This is in contrast to presenting a simple language that only covers simple situations. In the latter case, the actual complexity is passed on to the engineer.

Labels: , , , , ,