XML CO538 Anonymous Questions and Answers Keyword Index

This page provides a keyword index to questions and answers. Clicking on a keyword will take you to a page containing all questions and answers for that keyword, grouped by year.

To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.

Keyword reference for initial

Question 10 (2011):

Submission reference: IN2040

The following will compile:

    PROC test (CHAN INT out!)
      WHILE TRUE
	INT x:
	out ! x
    :

and will output "-1431655766". What's significant about that number?

Answer 10:

Your code declares a variable, x, and outputs its value down a channel. That value has not been set and, therefore, may be anything, :(.

In occam-pi, there is no automatic initialisation of variables to some default value. From the point of view of engineering, that's a good thing ... because what that default value should be depends on the application.

In Java, object fields are always initialised to something (number types to zero, object types to null) ... unless, of course, you assign it yourself to some initial value in the declaration (which I always do, even when that value is zero or null). But do you know to what value Java char fields are auto-initialised?

Java has a different rule for local variables (declared within methods or constructors). For these, there is no automatic initialisation of values (same as occam-pi) and, if your code tries to use those values, the compiler declares an error and refuses to compile. That is a good thing ... and, IMHO, Java should have this rule for object fields as well.

The occam-pi compiler only issues warnings about uninitialised variables, but lets them compile anyway. This is a temporary state ... because something has broken in the uninitialised tracking logic of the compiler and, when things get more complex, it gets this wrong, :(. When this gets fixed, these compiler warnings will be replaced with errors and the compilation refused. Meanwhile, take seriously all compiler warnings and ask yourself if you need to respond!

So, what happens if you use the value of an uninitialised occam-pi variable and have ignored the warning from the compiler? Well, the variable gets the bit-pattern left in whatever piece of memory it's been allocated ... which could be anything (especially for pieces of memory re-allocated during runtime).

However, for security reasons, many runtimes clear all memory to zero before running a program.

The Transterpreter takes the same care, but (I need to check this!) clears all memory to the bit-pattern "10101010101010101010101010101010" (which is -1431655766 in decimal ... I think!), just because that is a value that is most unlikely to be the default value you want ... and you will notice this ... and do something about it!

For the same reason, the KRoC runtime also clears its memory, but less excitingly to the smallest integer (-2147483648).

Clearing memory to zero is not safe, for the same engineering reason that auto-initialising number variables to zero is not safe: for many cases, initialising to zero is what's wanted ... but not for all cases. If we are lazy when coding and rely on auto-initialisation when we shouldn't, the bug from an incorrect variable initialisation to zero (which manifests itself some time later) may be difficult to find. If we are lazy when coding and rely on auto-initialisation at any time, getting an initial value of -1431655766 (or -2147483648) will probably be more noticeable!

Keywords: initial , q2

Question 18 (2009):

Submission reference: IN1817

Suppose we have a process P with state x. This state requires an initial value, and changes value based on periodic inputs from channel c. To provide the initial value there seem to be two options:

(1) wait for something to arrive on channel c before kicking off the main body of the process (see P1). This requires instantiating the process in parallel with another, which must be guaranteed to provide an initial value on channel c:

    PROC P1 (CHAN INT c?, ...)
      INT x:
      SEQ
        c ? x
        WHILE TRUE
          PRI ALT
	    c ? x
	      ...  some process that uses x
	    ...  some guard
	      ...  some process responding to the guard
    :

or (2) provide the initial value to the process as a value parameter (see P2):

    PROC P2 (VAL INT initial.x, CHAN INT c?, ...)
      INITIAL INT x IS initial.x:
      WHILE TRUE
        PRI ALT
          c ? x
	    ...  some process that uses x
          ...  some guard
	    ...  some process responding to the guard
    :

Does it matter which of these we do, and which is considered nicer? Are we looking at lost marks for doing one over the other?

Answer 18:

Either of your options will work. Both of them requires another process in parallel with this one in order to drive its input channel c.

If it is a natural part of a specification for that other process to supply the initial value for the state of this one, then P1 is the right solution for this one.

If that initialisation is not a natural part of a specification for that other process, it should not be made to do it! Instead, your P2 solution – where its initial state value is given explicitly in its instantiation – is the right solution.

Yes, you would lose some marks for not choosing the right solution for any problem. A working solution is not enough for full marks.

For interest only: for some time, we have been meaning to introduce INITIAL as a qualifier on data parameters (like VAL). The meaning is that an initial value must be given to that parameter (like VAL), but that it may be changed by the code body (unlike VAL parameters) and that its final value is not returned to the invoking process (unlike reference data parameters - i.e. those without any qualifier). With this mechanism, your P2 version would not need its local INITIAL declaration - i.e.

    PROC P3 (INITIAL INT x, CHAN INT c?, ...)
      WHILE TRUE
        PRI ALT
          c ? x
	    ...  some process that uses x
          ...  some guard
	    ...  some process responding to the guard
    :

We really must get around to putting that into the language ... !

Keywords: initial