Question

My occam-pi application has a long running producer process defined as follows:

PROC producer (VAL INT start, step, CHAN OF INT c!)
  INT count:
  SEQ
    count := start
    WHILE TRUE
      SEQ
        c ! count
        count := count + step
:

It sends a value on the channel c increasing from start by step. A full example is available here.

This works great, and I'm led to believe that infinite loops are idiomatic in CSP. The problem arises when my consuming algorithm is finished. In this example, a deadlock occurs once the consumer finishes.

The TAGGED.INT protocol described here attempts to solve the problem of shutting down a network of processes, however, from my current understanding there is no simple method for terminating a producer whose primary job is sending on a channel. It feels like the only method of halting a producer is to use some sort of control channel and black hole the output:

PROTOCOL CONTROL
  CASE
    poison
:

PROTOCOL TAGGED.INT
  CASE
    normal; INT
    poison
:

PROC producer (VAL INT start, step, CHAN OF TAGGED.INT c!, CHAN OF CONTROL control?)
  INT count:
  INITIAL BOOL running IS TRUE:
  SEQ
    count := start
    WHILE running
      SEQ
        PRI ALT
          control ? poison
            SEQ
              running := FALSE
              c ! poison      -- necessary, only to kill the black hole process 
          SKIP
            SEQ
              c ! normal; count
              count := count + step
:

A full working example is available here. The problem with this is that the code is much more unreadable - subjective, I know, but important for software engineering - the original intent is convoluted compared to the original. It seems contradictory to Occam's Razor!

With JCSP, C++CSP2 and python-csp a channel can be explicitly poisoned in order to shutdown a network of processes. For some reason wrangling occam to do this pollutes the code with shutdown logic and seems illogical.

So the question is, is there a method of terminating a producer process without the use of an explicit control channel as in the example?

EDIT:

There is potentially more information on this topic contained within this mailing list archive (Poison), this is quite old (> 10 years). So the question still stands, has anything changed since then, or is this the best way of achieving 'process termination' in occam-pi?

Was it helpful?

Solution

So the question is, is there a method of terminating a producer process without the use of an explicit control channel as in the example?

As long as the decision to terminate originates from outside the producer process, there is no other way than to use a (control) channel. It is because in the distributed-memory model the information has to be communicated via a message.

That said, the poisoning method you refer to is a general method, and it can be made to work in this case too. The reason it pollutes the solution is that the original (non-terminating) producer process only sends messages, but does not receive any. For the poisoning method to work, the producer has to be prepared to accept messages, and - what is even more inconvenient - the consumer has to be prepared to deal with a sluggish producer.

I would consider using a different technique to solve the problem: the producer would get a signal after each message sent whether the consumer want it to continue or not. This would result in more traffic, but the structure of the solution is clearer this way.

Occam 2.1 code:

PROC producer( VAL INT start, step, CHAN INT data, CHAN BOOL control)
  BOOL running:
  INT  count:
  SEQ
    count, running := start, TRUE
    WHILE running
      SEQ
        data    ! count
        control ? running
        count := count + step
: -- producer

PROC main( CHAN BYTE inp, out, err)
  CHAN INT data:
  CHAN BOOL control:
  VAL INT amount IS 10:
  INT val:
  PAR
    producer( 0, 4, data, control)
    SEQ n= 1 FOR amount
      SEQ
        data    ? val
        control ! n < amount
        out.int( val, 0, out)
        out.string( "*n", 0, out)
: -- main
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top