A parallel example of running horses in parallel with scoop

Concept

The concept is to have separate horses running in parallel, started from APPLICATION class. To avoid running into dead locks, the status of the horses is delegated to a STATUS_DISPLAYER class which does the io.put_string.

Running an application through pure object oriented trying to access the position of each horse object has to be avoided, as each horse will be locked into its run procedure which does a loop till finish. For that reason each busy horse will be locked during the run process and its position won't be available for querying.

To achieve displaying the status of all horses at one time (instead of an unreadable result of displaying each horse step) the use of the STATUS_DISPLAYER is done.

Two different implementation where recommended to me and updated as a different object, keeping the position of each horse and displaying all horses status at once each time one of them has changed, called as set_horse_status.

The development of these examples was highly helped by Alexander Kogtenkov and others following a google groups discussion on eiffel SCOOP I initiated to understand and train the SCOOP model.

Note that on illustrations

• The squares are to define SCOOP processors (separate objects)
• The dotted black arrows define client links from an object to another
• The red arrows shows the process of call stack from an event to another

Implementations

Following the suggestions of Alexander Kogtenkov two different models could be applied on this type of situations

STATUS_DISPLAYER with STATUS_KEEPER

1. STATUS_DISPLAYER with STATUS_KEEPER option (Implemented into state_example_branch)

   Create a set of independent separate objects that will be used to store the state of a horse (Implemented as STATUS_KEEPER). The objects will be reachable from horses (one state object per one horse) and from the displayer (Implemented into STATUS_DISPLAYER ). The feature "run" of HORSE will update the state on every step, and the displayer will retrieve it on every step. Because the state object is idle most of the time, the information will be accessible most of the time.
   Record the state in the displayer directly. The displayer will not have any active behavior, it will only render current state of all horses after every update from a horse.
   -- Alexander Kogtenkov

In the illustration below:

• The application class, creates a horses list, the separate horses, the separate status_keepers, the separate status_displayer. Then the horses list is looped to call run on each horse.
• The run procedure calls the status_keeper.set_position (incremented_position) which itself calls the status_displayer to display the status of the horses run. When a horse finishes to run, a test is done to see into status_keepers to see if all horses have finished running and if so the ranking is displayed.
  

STATUS_DISPLAYER only

• STATUS_DISPLAYER only option (Implemented into the user_friendly_version branch)

  Record the state in the displayer directly. The displayer will not have any active behavior, it will only render current state of all horses after every update from a horse.
  -- Alexander Kogtenkov

In the illustration below:

• The application class, creates a horses list, the separate horses, the separate status_displayer. Then the horses list is looped to call run on each horse.

• The run procedure calls the status_displayer.set_horse_position (incremented_position) which itself calls the displaying of the status of the horses run. When a horse finishes to run, a test is done to seeif all horses have finished running and if so the ranking is displayed.