CAU

- The Model Railway
- - Software
- - - libRailControl
- - - - Constants/Functions
- - - - Process Comm.

Process Communication Framework

enginecarcar

A control program has basically to decide wether a train may enter a certain block or not. There are generally two ways of implementing the mechanisms for meeting these decisions:

  • There's one process for all block sections.
  • There's a process for each block section.

Students participating in the lab courses have to follow the second way. Therefor the files "/home/railway/inc/process.h" and "/home/railway/template/main.c" are supplied. In "main.c", for each block section there's a frame yet free of code, that will be compiled to the corresponding process. Each process created for a block section is only allowed to request the following informations and modify the following settings via library calls:

  • Get the readings of both velocity meters (if present).
  • Get and modify the speed value of this block.
  • Get and modify the operation direction within this block.
  • Get and modify the point position of all points within this block (if present).
  • Get and modify the realy position (only OCIC_LN_2 and ICOC_LN_2).
  • Get and modify the set signal position of all signals protecting the block (if present).
  • Get the signal position of all signals placed aside the block (if present).
The compliance to this rules is only watched by the PERMISSION versions of the library.

For getting informations concerning other block sections, a process has to send a request to the appropriate process. The other way round, a process has to answer all requests sent to him again by sending a message.

To free the application programmer from the need of implementing the message passing facilities, they are provided with the library. The function prototypes and constants are located in "/home/railway/inc/process.h" and "/home/railway/template/pstate.h".

The block section processes are only being regarded conceptually as processes. In fact, they are still part of the main()-routine where they are being invoked in a round robin fashion. Each process runs as long as it terminates itselfs, so the application programmer has to provide a cooperative process behaviour.

By using this process communication framework, students are introduced to the problem of creating a program in a "distibuted memory system" environment. Consequently, they should get a view for at least some sort of problems which come up when an application runs distributed, e.g. over a network (LAN, Internet etc.) or on a multi-processor system.


Clemens Grelck
generated on: Mon May 31 10:21:01 MET DST 1999