kent logo

CO538 Anonymous Questions and Answers

This page lists the various questions and answers. 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.

We have taken the liberty of making some minor typographical corrections to some of the questions as originally put. Although most of the questions here will have been submitted anonymously, this page also serves to answer some questions of general interest to those on the course.

When asking questions, please do not simply paste in your code and ask what is wrong with it, as these types of question are hard to answer in a public forum (resulting in either no answer, or an answer which will only be of use to the person asking the question). In many cases, a question about code can be formulated in general terms. For example, if you have an `IF' block that results in an `incorrect indentation' error, you might ask, ``what is the correct syntax for an occam `if' statement ?''. Questions of this form are easier to answer, and are meaningful to all.

Questions that are not suitable for these public pages (i.e. those that contain assignment-specific code), should be mailed to your seminar-leader.

Question 21:

How do we get the terminal to beep? Is there a character we need to send?

Answer 21:

See Question 18 (2000). One thing that answer didn't mention, though, is that you probably will also need to output a FLUSH to the screen channel (after sending the BELL). Otherwise, Unix buffers characters sent to the screen until either the buffer gets full or a new-line is output. So, if you want that beep straight away - rather than at the end of the current line of output - don't forget to FLUSH.

Reminder: please look through (and maybe print out) all questions and answers from previous years before re-asking them ...

Keywords: bell , beep

Question 22:

When we send the bell command to the screen is the internal speaker meant to beep, as mine doesn't. All I get is a symbol of a bell in the lower window. Is this correct? Thanks.

Answer 22:

Unix shell windows (e.g. xterms and xvts) can be set to respond to the bell character (ASCII code 7) in several ways. These include:

That response is not up to your occam program - all it can do is send the character. Setting that response may be possible ... but you'll have to explore the idiosyncracies of your terminal emulator.

Keywords: bell , beep

Question 23:

I'm trying to edit question 4 for the assignment but when I open it using 'gvim q4.occ' it opens but is just black and white text and it beeps at me!

Answer 23:

Check the answer to Question 16 (2002). Note: starting work for an assignment the morning that assignment is due is probably not a good strategy ...

Keywords: q4 , gvim

Question 24:

Is there a specific way in which the PROC's of a .occ file are compiled? I moved a PROC from the bottom of my file to a place that looked neater to me and the compiler had a small barny at me! Does the compiler follow a set pattern? Thanks

Answer 24:

The order in which things are declared in occam does matter. Only once something has been declared can you use it. So, unlike Java, you can only invoke/instantiate/call (whatever you like to call it) PROC's that are in scope - i.e. after their declaration.

Also, the kroc compiler assumes that the last outermost level PROC is the one from which execution starts ... and that that PROC has just the three standard channels for keyboard input, screen and error output. Again, this differs from Java - which looks for a public method called main, with a special parameter signature, but which can occur anywhere in the listing of the class code.

Keywords: compiling , undeclared

Question 25:

What does each of this mean?

  /\, \/, ><, >> and <<

Answer 25:

These are described in slide 4-35 and section 1.2 of the Checklist paper. From there, you can infer that they are infix binary operators between INTs and that they return INTs. However, those pages does not say what those operations were! For that, you need to have attended the lecture when they were presented.

They are (mostly bitwise) logical operations:

  /\  - bitwise anding (between the two operands)
  \/  - bitwise oring (between the two operands)
  ><  - bitwise exclusive-oring (between the two operands)

  >>  - logical shift right (by right-operand number of bits)
  <<  - logical shift left (by right-operand number of bits)

The logical shifts are the same as in Java. They are not circular shifts - zeroes are pulled in to fill empty bits.

There is also the prefix unary operator:

  ~   - flip all the bits in the operand

These operators enable low-level (i.e. efficient) bit-twiddling to be done. This is needed to access specific bit fields common, for example, to memory mapped registers.

Note: these operators are overloaded so that they can be used on INT16s, INT32s, INT64s and BYTEs, as well as on INTs. The two operands must be exactly the same type - and the result of the operation is that same type. The bitwise operators are associative - for example, we may write:

  a /\ b /\ c

without any brackets. This contrasts with the + operation, which require brackets for a three-way add since, of course, with fixed precision numbers:

  a + (b + c)   is not equal to   (a + b) + c

and so we have to put in brackets to say what we want!

Keywords: operators

Question 26:

I get this funky error and don't know what it means and how to solve it. Any tips would be appreciated.

  Simple input is not allowed on a channel with a tagged protocol

It happened when I tried to store a NAME.NUMBER using:

  in ? nameTemp; scoreTemp

Answer 26:

NAME.NUMBER is a tagged - sometimes called a CASE or variant - protocol. See slide 10-21, section 7.3 of the Checklist paper or the display process in q6.occ, for how to input from a channel carrying such protocool. It should be somelthing like:

  in ? CASE
    ...  local delarations
    string; length::nameTemp; scoreTemp
      ...  response to name-mark code
      ...  response to poison code

Keywords: q6 , protocol

Referrers: Question 53 (2003) , Question 27 (2002)

Question 27:

In the main cycle of Display in q6 it has the line:

  string; name.length::name; mark

Could you please explain what it is doing and how to use it?

Answer 27:

See the answer to Question 26 (2002).

Keywords: q6

Question 28:

I've noticed that the anonoymous question page hasn't changed for a while now. Is this because no one is asking questions or due to a delay in updating it?

Answer 28:

There have been very few recent questions (Q24..Q27). These answer pages were brought up to date about 7 hours before this question was posted ...

Keywords: questions

Question 29:

The random function says that it needs an integer at least 1. At the moment my seed is:

  id + modified.time

I know that my id can equal zero. You said that time could be negative, so I assume that it can equal zero as well. At the moment my modified time is:

  t /\ #7FFFFFFC

I have a vague understanding ofhow this works, but it looks to me that my modified.time can equal zero aswell, making it possible to break the random function. Do I need to change the bitvalue that I /\ with t?

Answer 29:

Your id and the timer value could both be zero - the latter could be negative as well! So, your concerns about the ideas above are valid. Check out the answer to Question 69 (2000), especially David Wood's suggestion at the end.

On a general point, you are strongly advised to browse through the anonymous questions and answers from previous years. On animating the Dining Philosophers, there was much discussion and plenty of good advice. For example, look at Question 68 (2000) ... and lots of others.

Keywords: random , q7

Question 30:

How many lines of code, rougly, is your solution to q7-dining philosophers?

Answer 30:

The source code for the model answer executable, answers/a7, has 382 lines. These include all the lines in your starter file, exercises/q7.occ, which has 106 lines. So, it can be done with just 276 new lines ...

Keywords: q7

Question 31:

I would like to use colour in my solution to Q7. The PROC fg.col in shared_screen.occ looks useful ... however, I am unable to use the shared_screen.occ code. I have the following lines at the top of my source code:

  #INCLUDE "shared_screen.occ"
  #USE "shared_screen.inc"

Many errors are generated relating to this, such as:

  Error-oc-shared_screen.occ(337)- pc subscripted too many times
  Serious-oc- Too many errors, maximum is 100.

What am I doing wrong?

Answer 31:

Sorry - we hadn't told you how to use this package. It's not part of the basic "course" library! Before explaining how to access, let me stress that noone needs to find out about and use this stuff - it's only there to provide a rich set of drawing mechanisms for those who want to do some really fancy animation. Even then, you don't have to use it ... but you will end up inventing something similar.

Something anyone could have done is simply copy those two files:


into the start of your own q7.occ file. Then, your own code could simply use anything defined in them. Note that the order is important - the shared_screen.inc must go before the shared_screen.occ file (which uses protocols and data types defined in shared_screen.inc).

Better would be to copy those files into the same directory as your q7.occ file and start your file with:

  #INCLUDE "shared_screen.inc"
  #INCLUDE "shared_screen.occ"

Again, note the ordering! These directives simply tell the compiler to pull in those files at the point of those #INCLUDEs.

Best is not to copy those files at all and use the library. All you haven't been told is the name of the library - which is "ss". Currently, only PROCs and FUNCTIONS are saveable in kroc libraries, which means that constants, data types, prototcols (etc.) have to be pulled in as #INCLUDEs. Anyway, to do this, your file needs to start with:

  #INCLUDE "ss.inc"
  #USE "ss.lib"

These can be followed, or preceeded, by other library accesses - e.g.

  #INCLUDE "consts.inc"       -- standard course library constants
  #USE "course.lib"           -- standard course library

We're not quite done. When compiling, the occam compiler (invoked by the kroc shell script) will find the relevant files. [Note: those working with the Linux kroc need to ensure their OCSEARCH environment variable is set up correctly.] When doing final linking (also invoked by the kroc shell script), we have to tell the linker where to find the library code. In fact, the kroc script uses the standard gcc (Gnu C Compiler) to do this linking - i.e. something different from OCSEARCH happens. Anyway, the compile command needed is:

  kroc q7.occ -lss

Linux users have always had to do something like this to link in the course library (which the kroc script on Solaris machines has been set up to do automatically). So, on Linux, if you want both libraries linked in to your executable, the command is:

  kroc q7.occ -lss -lcourse


Keywords: q7 , colour , animation

Question 32:

[Answering two questions here ...]

I was wondering what topics in the course text are not examinable?

and ...

For the JCSP stuff we're covring now, do we only need the course slides, jcsp.ppt? The JCSP home page seems to have slides for jcsp, jcsp.net, csp-java-model etc..

Answer 32:

Only material covered in the lectures or the seminars is examinable. This excludes slides 7-22 through 7-42, all of the chapter 9 slides and slides 10-24 to the end. Also, I don't expect you to remember details of transputer architecture (slides 7-3 through 7-7) - that was given just to present ideas of hardware description. All the printed papers in the course booklet (except the ones on GOTO and Emulating Digital Logic) were covered - but those missed out make useful background reading. The High-Level Paradigms paper was only partly covered - sections 4.5 and 4.6, But the rest is highly educational!

On JCSP, we are only going to work through the slides in jcsp.ppt. The other stuff should be of interest - but is definitely not examinable. Maybe, some may be interested in final year project work in this area though ...

Keywords: exams , jcsp

Question 33:

Hi, it has been strongly suggested by our seminar leader that we use protocols for the state report channels to the display process. The reports disclose the any change is state from the philosphers, forks and the security guard. Obviously you need to fair multiplex all the philosphers together and all the forks??? However, how can you multiplex three different protocols together??? You can't can you? If not, then I guess we write some display process with three input channels one for each protocol, and work that way.

Answer 33:

Fair mulitplex the philospher reports down to one channel. Same for the forks. That leaves 3 channels, with different protocols, coming to the display process - say a, b and c. To fair-alt those:

      PRI ALT
        a ? ...
          ...  react to the a mess
        b ? ...
          ...  react to the b mess
        c ? ...
          ...  react to the c mess
      PRI ALT
        b ? ...
          ...  react to the b mess
        c ? ...
          ...  react to the c mess
        a ? ...
          ...  react to the a mess
      PRI ALT
        c ? ...
          ...  react to the c mess
        a ? ...
          ...  react to the a mess
        b ? ...
          ...  react to the b mess

Bit repetitive writing the reaction codes thrice ... so make a PROC for each reaction ... just invoke that PROC thrice.

However, simpler-but-more-dangerous is just to have one protocol that all philosophers, forks and the security guard to use - that's 11 channels, all with the same super-protocol, coming out of the college. Plug those into the display and simply fair-alt that!

It's unsafe to use one protocol for all reports - since a fork, for example, could send a philosopher report by mistake! This is the sort of thing that can happen somewhere down the life-cycle of a product during maintenance. However, for this exercise, you will not lose marks for doing so ... so long as, of course, you don't make any mistakes that this approach allows!

Keywords: q7 , fair-alt

Question 34:

This is part of my display proc which reads in the reports from philosophers and prints the relevant thing:

  ALT i = 0 FOR 10
    in[i] ? CASE
      ...  etc.

and this is some of my protocol:

  PROTOCOL report
      thinking; INT
      sitting; INT

I'm getting the error:

  Error-oc-q7.occ(132)- Not enough items in i/o list

is this something to do with the type of ALT I am using or the protocol?

Answer 34:

Your ALT is wrong - the protocol looks OK. As the error message says, you have not supplied enough items in your i/o lists. For instance, to match the pattern defined by your thinking tag, you must follow the tag with an INT variable:

  ALT i = 0 FOR 10
    INT index:
    in[i] ? CASE
      thinking; index
      sitting; index
      ...  etc.

Keywords: protocol

Question 35:

Can you see why it is moaning about the indentation of the SEQ?

  ALT i = 0 FOR 10
    BYTE n:
        in[i] ? CASE

Answer 35:

Your don't show the context of your code. Assuming the first line is legally indented, the rest would be ... except, of course, that it's illegal syntax for other reasons! An ALT guard cannot be a WHILE-loop!! Did you mean to write something like:

  ALT i = 0 FOR 11
    BYTE n:
    in[i] ? n
        out ! n
        WHILE n <> FLUSH
            out ! n
            in[i] ? n


Keywords: incorrect-indentation

Question 36:

Do we need to design the philosopher system to end "gracefully" like in previous assignments?

Answer 36:


Keywords: q7 , graceful-termination

Question 37:

Could you please explain a little more how you would go about implementing the random time delay? I have read through the previous questions on it but I'm still a little lost. Is the time delay between philosophers doing different actions or in the display process?

Answer 37:

It's in the philosopher processes - not the display.

The question says:

Thinking and eating by the philosophers should be modelled by random (but finite!) delays

In the "philosopher" process there are two folds:

  <!--{{{  think-->


  <!--{{{  eat-->

You should replace the SKIPs by random delays.

Keywords: q7 , random , timers

Question 38:

Taken from the module webpage:

The course does not take a historical approach (e.g. through the study of semaphores, monitors and traditional threads standards such as posix)

Yet your notes say that fork is a simple semaphore - why are we set an assignment using something we haven't studied?

Answer 38:

The course neither teaches nor requires any knowledge of semaphores, monitors, posix etc.. Slide 6-60 defines a fork process purely in terms of channel communication and ALTing. In passing, it notes that a fork is a simple semaphore. If you had been at the lecture, you would have known that this is a remark directed at anyone who happens to know about semaphores and might be interested in comparing ideas. If you don't know what a semaphore is, the remark can be safely ignored until such time that you do. In no way are you expected to know anything about them for this course, its assignments or its exam.

Keywords: course

Question 39:

How do I state in occam that I want to use utils.occ? Thanks in advance.

Answer 39:

All your starter files (e.g. q7.occ) already have this set up for you. To answer your question, kroc supports a library mechanism for occam, the details of which are explained in the Linux release (in the essentially-kroc file). The utils.occ material is part of the course library supporting this course. To have access to that library, just put:

  #USE "course.lib"

before you need anything defined in that library (e.g. at the start of your code). Some standard constants (e.g. VAL BYTE FLUSH) are also useful. Currently, VALs, PROTOCOLs, DATA TYPEs (not studied) and CHAN TYPEs (also not studied) cannot be compiled into libraries and have to be included as source code. To get the standard constants needed for some of the course exercises, just put:

  #INCLUDE "consts.inc"

before you need them. Your starter files also have this.

Keywords: course-library

Question 40:

How much of the JCSP stuff is examinable?

Answer 40:

Look at the slides on the Co516 web page, under the link:

  JCSP course slides (3/02/2003)

All of them contain information that is relevant. However, before slide 62, this information is mainly revision of ideas. They do include some formal CSP notation, but this is for information only and not examinable. The important stuff is from slide 62 onwards, which presents the JCSP process structure (slide 65), the core API and examples of its use. Slides 125 through 132 (on graphics and GUIs) are not examinable. Neither is anything on the JCSP Networking Edition (slide 144), accessible through the main JCSP web page.

Keywords: exams , jcsp

Valid CSS!

Valid XHTML 1.0!

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.
Last modified Mon May 20 13:50:23 2013
This document is maintained by Fred Barnes, to whom any comments and corrections should be addressed.