MULTIPROCESSING WITH SMALLTALK/V

This article contains the following executables: AYERS.ZIP

Kenneth E. Ayers

The origins of object-oriented programming in general and Smalltalk in particular are closely tied to the simulation of real-world events and systems. A primary reason for this association is Smalltalk's facility for describing the behavior of a simulated system in terms of those real objects with which the implementor is familiar. Thus, the programmer of a highway traffic simulation can create car objects and truck objects and give them behaviors that mimic their real-world counterparts. Likewise, someone who is studying the flow of people through supermarket checkout lines can create objects representing customers, checkers and baggers and have them carry out actions that are familiar to anyone who has spent time waiting behind a shopping cart.

As an added benefit, extensible systems such as Smalltalk permit the developer of a simulation system to construct his or her own task language with which to describe the flow of information back and forth between the various participants in the simulation. This task language then becomes a part of the development system.

Until recently, though, the availability of object-oriented languages such as Smalltalk were limited to those using powerful (and expensive) workstations or minicomputers. Fortunately, that changed when Digitalk (Los Angeles, Calif.) introduced Smalltalk/V and its more powerful brother, Smalltalk/V 286. And, with a growing community of devoted followers, third-party support has finally begun to emerge. Because Smalltalk is such an open-ended system, this support commonly assumes the form of toolkits that extend the capabilities of Smalltalk's built-in environment. One such toolkit is the CX Multiprocessing Extension Kit from Computas Expert Systems.

The CX Multiprocessing Extension Kit (the Kit) provides many useful extensions to the Smalltalk/V or Smalltalk/V 286 environments. Within its 15 separate modules, the Kit provides extended functionality ranging from basic utility methods all the way up to a complete data acquisition class hierarchy. As is expected in the Smalltalk world, source code is provided for all of the classes and methods; and filein's (scripts to read source code into the Smalltalk system) are available for installing each of the modules. Briefly, the modules include:

• Basic Extensions -- are general methods used by other modules in the Kit
• Process Extensions -- support the creation of named processes, binding variables to a process, and assigning process priorities
• Semaphore Extensions -- provide enhancements to inter-process communications including named semaphores, limited-capacity semaphores, and synchronized message queues
• Screen Controller -- allow updates to partially obscured windows and displaying variable graphic information over a constant background image
• Process Status Window -- implements a standard window for real-time monitoring processes and semaphores
• Date/TimeServices -- enhanceSmalltalk/V with the ability to format date and time output, and convert between formats
• Event Queue Mechanism -- adds timed events (either relative or absolute date/time) and a monitor process that watches the system's clock for event triggers
• Acknowledge Mechanism -- permits a background process to temporarily gain control of the user interface for the purpose of acknowledging or verifying actions
• Data Acquisition Protocol -- implements a class hierarchy, under the abstract class Instrumentation, that provides a complete Smalltalk/V interface to the MicroMac 4000 controller from Analog Devices. The protocol, which serves as a functional template, can be modified to support other types of instrumentation controllers and subsystems
• Miscellaneous Extensions -- contain six additional modules not directly related to multiprocessing including a Form Inspector that displays the contents of a displayable image; enhancements to Smalltalk/V's Freehand Drawing (that is, painting) application and its associated Bit Editor; improvements in the behavior of the built-in TextEditor class; new versions of the class Browsers; and an Application Browser

Several of the extensions provided by the CX Multiprocessing Extension Kit depend upon capabilities added by one or more of the Goodies disks available (as options) from Digitalk. These dependencies, as well as the dependencies within the Kit's internal modules, are clearly specified in the documentation.

Of primary concern, however, is the lack of support for multiprocessing in the original Smalltalk/V. Users of Smalltalk/V must install the Goodies #l package before any of the CX multiprocessing extensions can be used. Users of Smalltalk/V 286 do not have this concern.

Otherwise, the Data Acquisition Module depends upon the Digitalk Communication Kit (for serial communications); the Freehand Drawing extensions depend upon Goodies #1 (to load and store images); the Text Editor extensions require Goodies #2; and the Browsner and Application Browsner modules need both Goodies #2 and Goodies #3.

One further note must be offered because it presents a problem when attempting to load the CX Multi-processing Kit. Smalltalk/V and Smalltalk/V 286 do not support floating point numbers without a math coprocessor present in the system. The CX Data Acquisition module is the only module that appears to require floating point capabilities. In order to load any other modules from the kit on a system that does not have an 80x87, the methods containsFloat and asFloat, in the Basic Extensions module (CXBSCEXT.PRJ), must be commented out. (Note: The Goodies #2 kit provides software floating point support.)

The evaluation copy I received was marked Version 1.0. It was supplied on a single 3.5-inch (720K format) diskette (a 5.25-inch format is also available). The data necessary to build the installation package has been compressed into several special .EXE files. One of two batch files (one for Smalltalk/V and one for Smalltalk/V 286) are invoked to initiate the creation of more than 60 source code and example files.

A concise, well written, 105-page manual describes each of the modules and provides simple installation instructions in the required sequence. The number of examples given in the manual is somewhat limited, although the Smalltalk/V source code for many others is available in various files. Consistent with Smalltalk/V's tutorial, these examples can be selected and executed using the File Browser.

The Smalltalk/V 286 Virtual Machine (its kernel) contains support for scheduling the execution of multiple processes with consideration for priority levels. In the context of Smalltalk, a process is a block of code that is capable of executing as an independent program. During its lifetime, a process can assume any one of several states: Active, the process is currently executing and "owns" the computer; Ready, the process is ready to run but is waiting to be scheduled for execution; Blocked, the process is waiting for some resource to become available or for some event to occur (for example, a signal from another process); and Dead, the code associated with the process has reached its logical point of termination.

A process is created by sending the message fork or forkAt:aPriority to a block. An example is [self run] forkAt:2. In response, the Smalltalk/V kernel will create a Process object, whose code is the expression in the block ('self run'), and schedule it for execution at the next available opportunity. That opportunity comes when:

1. The current active process terminates, becomes blocked or voluntarily relinquishes control by executing the statement Processor yield.

2. There are no other ready processes at a higher-priority level.

3. There are no other ready processes at the same priority level that have been ready for a longer period of time.

Note that Smalltalk's scheduling is non-preemptive or cooperative. There is no time slicer that periodically says "Okay process, you've had enough time. Time to let this other process have its chance." In Smalltalk, it's up to the programmer to assure that processes are "courteous" and periodically give others a shot at running the show.

By its very nature, multiprocessing capabilities are ideally suited to tasks such as industrial control and monitoring, and to a class of applications known as discrete event simulations. In both of these types of applications, multiprocessing allows each individual object participating in the application to be represented by separate processes. Processes communicate with one another by sending messages (via message queues) or by signaling (via semaphores) the occurrence of some event required for coordinating their activities.

To demonstrate the use of multiprocessing and apply some of the many features offered by the CX Multiprocessing Kit, I have included a simple application that provides an animated simulation of checkout counters at a typical supermarket. In this application, there are five basic classes of objects and processes:

1. Customer processes (instances of class Customer) enter a checkout line, wait to be served, empty their carts, and then leave.

2. Checkout clerk processes (class Checker) accept items from the customer and hand them off to be put into grocery sacks.

3. Bagger processes (class Bagger) accept items from the checkout clerk and place them into grocery sacks.

4. Checkout counter processes (instances of class CheckoutCounter) are assigned one checkout clerk, one bagger, and a queue of customers who are waiting to be serviced.

  Customer (upon removing an item from the cart):
                self
                             animate; "Lean forward"
                             send:#takeItem to:checker.

  Checker (upon receiving 'takeItem' command):
                self
                             animate; "Turn to left";
                             send:#takeItem to:bagger;
                             send:#gotIt to:customer.

  Bagger (upon receiving 'takeItem' command):
                self
                             animate; "Turn to right"
                             send:#gotIt to:checker;
                             display.  "Turn back forward"

  Customer (upon receiving 'gotIt' command):
                self
                             display.  "Stand up straight"

  Checker (upon receiving 'gotIt' command from bagger)
                self
                             display; "Turn back forward again"
                             send:#removeItemFromCart to:customer.

  Customer (when the cart is empty):
                self
                             moveTo:counter exitPosition; "Move to exit"
                             send:#nextCustomer to:counter.

  MarketImages := Dictionary new:7.
  MarketImages
                at:'PersonUp' put: (Form width:16 height:16).
  MarketImages
                at:'PersonRight' put: (Form width:16 height:16).
  MarketImages
                at:'PersonDown' put: (Form width:16 height:16).
  MarketImages
                at:'PersonLeft' put: (Form width:16 height:16).
  MarketImages
                at:'Customer' put: (Form width:16 height:32).
  MarketImages
                at:'CustomerReaching' put: (Form width:16 height:32).
  MarketImages
                at:'Counter' put: (Form width:32 height:64).

  |oldImage newImage|
  MarketImages keysDo:[:key|
                oldImage := MarketImages at:key.
      newImage := oldImage magnify:oldImage boundingBox
                by:2@2.   MarketImages at:key put:newImage].

  RandomNumber
  EmptyMenu
  MarketActor
    Bagger
    Checker
    CheckoutCounter
    Customer
  MarketSimulator
  MarketWindow

Open the simulation window by evaluating the expression MarketWindow new open. The simulation is started by popping up the pane menu, START SIMULATION, and clicking on it.

The basic multiprocessing capabilities found in the Smalltalk/V 286 environment are sufficient, with some ingenuity, to create fairly elaborate simulations. The methods and classes included as part of the CX Multiprocessing Extension Kit offer many much needed enhancements to those limited capabilities. This is particularly true of the classes EventQueue and Message Queue, which facilitate the implementation of timed events and interprocess communications. (When I first implemented the example application accompanying this article, I did so without using the message queuing capabilities. The result was extremely cumbersome and prone to unexplained failures. The decision to pass command messages between processes made the flow of information explicit and made the entire application much more understandable.)

The package offers an extraordinarily large number of features, all of which appear to be quite useful to the serious Smalltalk/V developer. Furthermore, there seems to be little evidence of redundancy or overkill. Some of the features, particularly the browser extensions, are worthy of a review by themselves.

One of the few real faults I could find was the lack of concrete examples. As seems to be common practice, many of the examples, while certainly complete and accurate, are rather trivial. To someone having limited experience with Smalltalk's multiprocessing features, that type of example fails to illustrate adequately the key concepts involved in creating and coordinating multiple processes. Personally, I would prefer to see one or two really complete examples than a hundred ways to print "hello world" using multiple processes.

From an operation point of view, the use of named processes and semaphores tends to impair Smalltalk's garbage collection and tends to leave inaccessible objects lying around unclaimed. In all fairness, this anomaly is documented; yet its occurrence is still disconcerting. I noticed that the use of the Process Status Window also seemed to produce a similar effect.

It is noted that the use of timed events creates a high-priority background process to watch the clock and look for events that need to be triggered. This appeared to affect the performance of other parts of my simulation, slowing it down considerably. Thus, for example, to implement a "sleep for n seconds" method, I found that watching the time myself produced better results than scheduling an event for n seconds in the future. Undoubtedly, for infrequent events occurring at some absolute date/time, this feature would be invaluable; but for short, repetitive delay operations it seemed to incur a considerable overhead.

Finally, though the cost of the extension package itself is certainly reasonable, the hidden costs of the Goodies, required to make full use of its capabilities, nearly triples the upfront cost of using this package. Even though the Goodies packages do offer a lot of added functionality at a reasonable price, I feel it only fair to warn the potential user that they represent an additional cost.

The net result of my experience exploring the CX Multiprocessing Extension Kit was certainly positive. I have gained additional insight into the realm of multiprocessing within the context of Smalltalk and feel certain that potential users of this package would benefit from its diverse capabilities.

But for now, I'm going to get back to my simulated market and see if I can answer the question that has plagued modern man since the opening of the first supermarket: Why is the shortest line always the slowest?

CX Multiprocessing Extension Kit Computas Expert Systems A.S (Veritasveien 1) P.O. Box 410 N-1322 Hovik, Norway Requirements: Smalltalk/V 2.0 or later Goodies disks #1, #2, and #3 Smalltalk/V 286, 1.1 or later recommended Price: $99.95

_MULTIPROCESSING WITH SMALLTALK/V_ by Kenneth Ayers