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 61:

Submission reference: IN2094

Task 3 of the mars assessment.

If the robot turns a full rotation (360 degrees), and hasn't found anything so therefore stops find.blob execution, should it return a value of 0 for new heading or is 360 acceptable?

Answer 61:

The instructions for Task 3 say: "return the new heading of the robot relative to the heading you started at". A heading of 360 degrees relative to the initial heading is the same as 0 degrees – so either figure is acceptable.

Keywords: mars

Question 62:

Submission reference: IN2095

For the Mars assessment, Do we just submit mars-main.occ?

Answer 62:

Thank you for this question. Perhaps we did not make it crystal clear! The fourth bullet of the Getting Started section of the Starting out on Mars web page says: "mars-main.occ. This is the file you'll spend your time editing, and eventually submit, as detailed in the submission guidelines." I've updated those guidelines in the Assessment 5 box on the Moodle page and repeat them here for convenience:

Please only submit your edited mars-main.occ file, together with process network diagram(s) if you have used concurrency in your implementation of the robot.control process. Network diagrams can be in the formats approved for earlier assessments (or could be handed in to the CAS office on paper with signed cover sheet). If you have changed any of the other files in this assessment's set of files, you must also submit those – together with a README file explaining the changes you have made. [Note: we do not expect you to have changed any files (other than mars-main.occ, of course)].

Keywords: mars

Question 63:

Submission reference: IN2096

Super Simple Question:

Will our marks be affected by the efficiency of Task 4?

Answer 63:

My demo answer takes a pretty long time for the rover to find its way to very roughly the midpoint between the two blobs. Sometimes it fails completely (e.g. when too many obstacles are in the way it wants to move).

Following a strategy that takes a long time to find a place, very roughly, where the sensor is to be deployed will definitely not be penalised!

Of course, unnecessary inefficiencies in lower-level logic will continue to be penalised.

As always, your code must be elegant and clean – well-chosen PROCs that abstract coherent pieces of logic, no repeated sections of code with only trivial differences (e.g. magic constants), sensible comments explaining aspects of your code that are not obvious (e.g. the high-level search strategy you have devised), etc.

Keywords: mars

Referrers: Question 69 (2011)

Question 64:

Submission reference: IN2097

Regarding Mars:

I'm having some trouble getting the hazard detection to work as I would like. I can receive the values and act upon them easily enough when moving – the problem is checking them prior to moving. I would like to check them before the robot moves; for example in the case were the robot has stopped for a hazard and then told to move again towards that hazard. I want the values I had previously so that I can prevent the robot from ever moving, until itís facing/moving away from the hazards.

The problem is that the values arenít persistent since the move proc ends so I have to request new values. However, the hazard monitor doesnít have new values since they only update when the values change (i.e. whilst moving).

I can see how I would do this with a request system: have my monitor run continuously, and ask for the hazard values whenever I need them, and then just keep asking every set amount of time whilst moving. However, this sounds like a bad solution. I would rather keep a system similar to my current one, in which I ALT on the hazard channel and respond based on the values. However I can't get it to work as a check before movement and at the same time work whilst moving.

Any tips or advice would be appreciated. :)

Answer 64:

As you say in your last but one paragraph, a request solution (see the answer to Question 59 (2011)) works but is awkward and inelegant – as it depends on choosing a suitable polling interval between requests (see the Postscript in the answer to Question 59 (2011)). The rest of that Postscript describes an elegant modification to this, but leaves you with a challenge to implement it in a way that avoids any possibility of deadlock.

The solution to that challenge is an example of a general, and very useful, concurrency pattern: the cancellable service. This is an extension to the pure client-server pattern (see Overview slides 39-43). In a cancellable service, a client can interact with a server in the normal way (send a request message, wait for reply). However, the client can also send a cancel message, following its request, if it has a reason that it no longer needs that service. The server must be able to receive and deal with such a cancel, even though it may be about to send a reply to the client – without causing deadlock. Dealing with a cancel would mean undoing any state change made in the server as it processed the now-cancelled request. Something to think about ... ;).

There's a sequential way to solve this problem (i.e. without installing a concurrent hazard monitor that provides a cancellable service) that may be easier.

You said: "the hazard monitor doesnít have new values since they only update when the values change (i.e. whilst moving)". That's true, but hazard values also change when the rover is turning. They could also change if other moving obstacles (e.g. other rovers) are on the scene – although that doesn't happen in the simulation environment you have been given. To cope with this, all hazard channels must be observed at all times and the most recent warning levels kept up to date. Of course, this is what a a concurrent hazard monitor does.

But this can be done sequentially. The robot.control process has various states that it goes through is various sequences: wait for an operator command, do a turn, do a drive, do a find and do a deploy. So, listen to the hazard channels when doing all these things, keeping the latest warning levels in an array that is passed to all implementing PROCs (as a reference parameter, of course). Then, when asked to do a drive, you have the current hazard levels in that array – so you can check before moving. The important thing is to monitor the hazard channels when turning, even though that information is not relevant for the turn itself. Although not necessary for the environment we have given you, monitoring the hazard channels when waiting for mission control commands is trivial to add (and useful, in case of aliens or other robots).

Everything said in the last two paragraphs applies also to monitoring the camera channel – just save the latest BLOB. Then, when told to find one and the rover is stationary, you may already have it!

Keywords: mars

Referrers: Question 68 (2011)

Question 65:

Submission reference: IN2098

Hi, I've been working on the move and turn parts of the mars assessment. I seem to have implemented the sensor section correctly, as my robot stops for obstacles, but refuses to stop other than this. Currently, I have a while loop that only runs while the total amount moved/turned is less than the amount given by the operator. This is worked out by adding each value being received on the feedback channel to the total distance travel. I can't seem to figure out why its not stopping.

Answer 65:

This sounds similar to the problem reported in Question 55 (2011). Check out its answer – especially the paragraphs following the one starting: "There are other problems though ...". Also, check out Question 58 (2011) and its answer – this question reports the same problem, but the mistake was for a different reason.

If these don't help, you have to post more information on your code. I'll edit out too much information before replying.

Keywords: mars

Referrers: Question 67 (2011)

Question 66:

Submission reference: IN2099

Can we leave the debug dumps (log!) in our code (I use it to display all the calculations and steps)?

If I leave it there, it messes up the operator response part of the output.

Answer 66:

If you have masses of log reports and the screen output is too messy, please comment them out ... but read on ...

A better way (than commenting) to switch on and off debugging reports is to declare somewhere close to the top of your program:

    VAL BOOL debugging IS TRUE:      -- for no debug reports, change to FALSE

and then to wrap all debugging reports with:

        ...  sequence of "log !" reports

Then, you can easily switch off debugging with a single-line change of the declared VALue of debugging to FALSE.

Set this FALSE for your submission. If your program does not work for some tasks, include a README.txt file in your submission that says what does not work and mention the debugging reports in your code and how to switch them on. Making it easier for your markers is always a good idea!

Keywords: mars , debugging

Question 67:

Submission reference: IN2100

In response to my earlier Question 65 (2011) about the never ending while loops, here's my code for the turn process. I've had a look at both the previous questions and they still don't solve my problem. Here is my turn process:

    PROC turn (VAL INT distance, CHAN INT output!, CHAN INTERNREP feedback?, 
               CHAN P.MOTOR.CMD sigsender!, CHAN P.MOTOR.FEEDBACK info?)
      ...  code omitted

The feedback channel in here is to gather info from the sensors. It delivers two items: a BOOL that indicates if the sensor is from the front or the back, and then the threat level.

Also, is it possible to use the AND operator to determine whether two expressions are both true? I've switched from using nested IFs to this method while debugging my code, but the computer is coming up with an error.

Answer 67:

[Note: although this answer is about code that is not shown, it should be worth reading by those other than the questioner since it describes misunderstandings about the problem and errors in approach that may be of help generally.]

You use the IABS function correctly on the info channel tick counts to accumulate always a positive total amount of turn. But you should also use IABS on distance (the commanded amount of turn) when checking to see if that total exceeds the commanded amount. Otherwise, if the turn were anti-clockwise (i.e. distance were negative), your loop would never end.

You also wait (inside the loop body) for sensor information (warning you about hazards) from your feedback channel. If none arrives, your code blocks at that point until some comes. Meanwhile, the rover keeps on turning and you keep missing ticks from the motor feedback info channel. It's not that the loop keeps looping ... it just gets stuck! This is almost exactly the same mistake as pointed out in Question 55 (2011) (the paragraphs following: "There are other problems though ...").

Also, if and when you do get sensor information from your feedback channel, the code you sent does nothing with it ... possibly because of the question you raise in your last paragraph?

In that last paragraph of your question: when you say "the computer", I assume you mean "the compiler"? If so, you must be having trouble with the syntax of boolean expressions containing boolean operators (AND, OR, etc.). Remember that occam-pi has no binding precedence for any of its operators – for the good reason that it's hard to remember them! So, when writing expressions with more than one operator, we must bracket them to group them in whatever way we want (what-you-see-is-what-you-get). For example:

      (x > y) OR (x > Z)
	...  do something
	... do something else


    WHILE (distance.turned < absolute.distance) AND (danger < theshold)
      ...  do something

Hope that helps ...

Keywords: mars

Referrers: Question 71 (2011)

Question 68:

Submission reference: IN2101

This is in response to my earlier Question 59 (2011). I have included some code that probably requires omission.

So far I have implemented it where hazard.monitor works in a client-server fashion, and move continuously checks the values until it reaches the destination. However I think I am polling? There doesn't seem to be an obvious solution to implement it in a non-polling fashion.

    PROC move (VAL INT move.mm, BOOL success, INT driven.mm,
	       CHAN P.MOTOR.CMD motor.cmd!,
	       CHAN P.MOTOR.FEEDBACK motor.feedback?, 
	       CHAN BYTE log!,
	       CHAN BOOL hazard.enquire!,
      INITIAL BOOL forward, continue, hazard.detected IS FALSE, TRUE, FALSE:
      [HAZARD.SECTIONS]INT hazard.value:
	success := FALSE
	...  get latest hazard values (from hazard.monitor process)
	...  if no hazards in movement direction, issue drive command to motors
	  continue    -- i.e. drive command was sent
	    CHAN BOOL stop.motor.monitor, stop.check.hazard:

		...  loop that listens on 'stop.motor.monitor?' and 'motor.feedback?'
		     channels.  If anything on 'stop.motor.monitor?', exit loop.
		     If anything on 'motor.feedback?', accumulate tick counts in
		     'driven.mm' and exit loop if 'move.mm' is exceeded.
		stop.check.hazard ! FALSE
	      ...  loop that polls 'stop.check.hazard?' (from above process) and
		   exits loop if anything is received.  In the loop, if poll fails,
		   get latest hazard values (from hazard.monitor process) and,
		   if hazard found in direction of travel, send 'stop.motor.monitor!'
		   message (to break the loop in the above process), wait for
		   'stop.check.hazard?' message, set 'hazard.detected' and exit loop.
	motor.cmd ! stop
	success := NOT hazard.detected

I'm unsure if there is chance of deadlock here? I haven't experienced any and it appears to work fine.

I have also managed to implement this move process in a sequential fashion where hazard levels are checked, then motor feedback and it loops back round. I believe this isn't too great though, as it reports it has moved 10mm closer to the hazard than when it detected it.

Answer 68:

Not bad, :), ... but there is the chance of deadlock (see below) and unnecessary inefficiency (busy polling). You also have a trivial typo error in your code for detecting hazards in the direction of travel of the rover (use of the 'BACK.RIGHT' index twice, instead of 'BACK.RIGHT' and 'BACK.LEFT').

Polling cannot be avoided with this design, since you have to send a specific request to the 'hazard.monitor' process (the second of your PAR components) at the same time as watching 'motor.feedback?' (the first of your PAR components) to see if the target distance has been reached ... and occam-pi does not support ALTing between a send and a receive.

However, your polling is needlessly busy! Your second PAR component gets new hazard levels each time the poll on 'stop.check.hazard?' fails (which takes around two or three nano-seconds and will almost always be the case). This is far too often and will keep a processor core at 100% and very hot! Rather than PRI ALT against a SKIP guard, PRI ALT against a timeout (set for, say, every tenth of a second ... which should be often enough, given the slow speed of the rover). The rover movement should be the same, but the processor loading should now be minimal (along with demands on its battery ... which is a key consideration for any embedded application).

Deadlock can happen with your design as follows. The loop in the first of your PAR components exits because the requested distance, 'move.mm' has been exceeded. At roughly the same time, the loop in your second PAR component detects a hazard and sends a 'stop.motor.monitor!' to the first component. That first component is no longer listening, because it's exited its loop and is trying to send a 'stop.check.hazard!' to the second component. Deadlock!

This deadlock is unlikely to show up ... but that's not acceptable! One day it will happen. The rover is on Mars and may be tricky to reboot, :(. There is a (fairly simple once you know it) way to avoid such deadlocks – and it's the same solution as is needed for implementing the cancellable service pattern (described in the answer to Question 64 (2011)).

However, it may be simpler to follow the suggestion in the last sentence of the Postscript of the answer to Question 59 (2011). For your code, combine the two PAR components into a single loop that ALTs between 'motor.feedback?' and a timeout (every tenth of a second). Respond to a 'motor.feedback?' in the usual way (exiting the loop if the target distance is achieved). Respond to a timeout by getting the hazard levels (exiting the loop if a hazard is detected). Simples, :).

The above may be close to the "sequential fashion" you mention ... but please use timeouts (not busy polling)! From your description, it sounds like you only check the hazard levels after every 'motor.feedback?' ... which is wrong (and would account for the 10mm overrun you report). You need to ALT ... as described in the preceding paragraph.

Hope this helps.

Keywords: mars

Referrers: Question 69 (2011)

Question 69:

Submission reference: IN2102

Hello, With regards to Question 63 (2011), what kind of inefficiency will be penalised?

Is it code-wise or in solving the task? I make a ridiculous number of sweeps over the same territory. My robot has amnesia.

Answer 69:

Code-wise. We will penalise programming inefficiencies that are needless ... like busy-polling (see the answer to Question 68 (2011)), recalculating the same thing more than once, testing variable values that don't need testing, searching more of an array than needs to be searched, etc.

Strategic inefficiencies in the plan for solving Task 4 will not be penalised ... so long as they are not too gross and easily avoided. A strategy that is infinitely inefficient (i.e. has no chance of success) will, of course, be penalised. A strategy that takes a long time, but gets the rover roughly to the required deployment point, is fine!

Keywords: mars

Question 70:

Submission reference: IN2103

all the tasks have been complteded, thing is, i never get a message back on the terminal. the robot moves/turns etc sucessfully, but then does nothing. im sednign the correct value on the operator respone channel, and the right hting happens on the screen. but just no messages on the termianl. any suggestions on how to fix this?

Answer 70:

If you send a correct message on the opr.resp! channel, it will be relayed to your screen. For example, just try sending:

    opr.resp ! turn.complete; 42

as an immediate response to any turn request (i.e. without actually doing anything!) to see the response relayed to your screen.

If your program turns the robot successfully (as seen in the animation window) but your screen shows nothing, it's because your code has not reached the line in your code where you send your response to opr.resp!. Try adding log! messages – e.g.

    out.string ("===> turn complete, about to send response ...*c*n", 0, log!)

just before your opr.resp! message. Do you see that log! message? If not, put in more log! messages further back in your code (e.g. into the loop in your turn logic ... does that loop ever exit?).

Time is short, but hope this helps!

Keywords: mars

Question 71:

Submission reference: IN2104

my hazards dont seem to be working. currently, i have a process that takes an array of hazard channels, and stores the values that come in on each of them using a replicated alt. it then sends that value out, zlong witha boolean variable to detrmine whither it is the front or the back set of sensros to any prcess that is connected to it, such as my move rpocess. the move prcess cheks the boolean to see if the sensor data is related tot he direction it is traveling in, if it is, then it should stop the rover. but it doesdtn seem to be. what would be the best thing to do to solve this?

Answer 71:

How often does your move process listen on the channel from the process you describe that forwards specific hazard warnings? Does it listen inside a loop in sequence, or in parallel, with listening to the motor feedback channel? If so, that is the same mistake as reported in Question 67 (2011) (para starting: "You also wait ...") and Question 55 (2011) (para starting: "There are other problems though ..."). Your problem is also similar to Question 58 (2011).

Please read carefully through those Q&As.

Keywords: mars

Question 72:

Submission reference: IN2143

hi, with regards to the exam, what would happen if we were to answer all the questions in part B, instead of only answering two?

Answer 72:

Part B has three questions and the rubric says to answer exactly two of them. If you answer three, I don't know the official answer. However, what has (I think) usually happened in the past is that all three answers will be marked and the two with the highest marks will be accepted as your formal answers (i.e. the answer with the lowest mark will be discarded).

Please note that this is not an official answer. For an official answer to the procedures for managing exam rubric errors by candidates, you must ask the University Exams Office.

Keywords: exams

Question 73:

Submission reference: IN2142

Supposing you have a process "plex" that ALT's over two incoming INT channels:

  PROC plex (CHAN INT in.0?, in.1?)
        INT x, y:
	  in.0 ? x
	  in.1 ? y

... with "plex" called using two "numbers" processes:

  PROC main (CHAN BYTE in?, out!, err!)
    CHAN INT a, b:
      numbers (a!)
      numbers (b!)
      plex (a?, b?)

Since only one guard is executed, why does the program not block? Will both x and y be set (and only a single body executed)? Could I write the following?

        INT x, y:
          in.0 ? x
              out.int (x, 0, out!)
              out.int (y, 0, out!)
          in.1 ? y

Answer 73:

In every loop of your plex process, only one ALT guard is executed – i.e. a communication from either one of its input channels is taken. Your main process does not deadlock since its two numbers processes will always offer to send messages and plex will always take a message from one of them. Were you forgetting about the WHILE-loop in your plex?

The last fragment of code in your question is wrong because the y variable in the second call to out.int is undefined. This fragment executes as follows: it waits for a message on either of its input channels; if it takes a message from in.1, it does nothing else; if it takes a message from in.0, it catches it in variable x and outputs ASCII bytes for its decimal representation down the out channel (which must carry BYTEs, otherwise the fragment of code would not compile) and then tries to do the same for the integer value in variable y ... but that value has not been set anywhere ... which makes no sense and is not allowed.

Keywords: alt

Question 74:

Submission reference: IN2144

Consider the following top level processes:

  PROC main.1 (CHAN BYTE out!)
    out.int (1, 0, out!)

  PROC main.2 (SHARED CHAN BYTE out!)
    CLAIM out!
      out.int (1, 0, out!)

The first prints "1", whereas the second prints nothing. Adding a FLUSH (or newline) "fixes" it.

Why does a SHARED channel introduce this behaviour?

Answer 74:

First, I confirm getting the same behaviour that you report (using KRoC under Ubuntu, version 11.04, Linux).

The need to flush characters sent to the screen channel depends on the operating system (if there is one) in which the occam-pi program is running. Both in the KRoC support for occam-pi (compiled code plus multicore scheduler) and in the Transterpreter (interpreter), we have tried to provide the behaviour that is normal for Unix standard output (which is that characters are buffered until either the buffer is full or a special flush character is received).

What happens to characters still in the Unix standard output buffer when a program ends is a grey area. It would be OK simply to discard them, as happens with your main.2 program. It would be OK to flush them out, as happens with your main.1 program. However, we ought to be consistent about this and we will see if we can do that!

Thank you for your question. It is really about the interaction between the occam-pi system and its host operating system. Please be assured that such matters are not part of the syllabus for this module and no questions requiring such knowledge would be asked in the exam on this module.

Keywords: flush , shared-channel

Question 75:

Submission reference: IN2145

In the exam are we expected to implement fair alting if the question doesn't explicitly ask it?

Answer 75:

Nope — if fair-alting is required, it would be asked for (indirectly though perhaps).

Keywords: fair-alt

Question 76:

Submission reference: IN2151

I am trying to run the Transterpreter, yet I get the error message "CreateProcess returned false" and thus cannot run the transterpreter.

Answer 76:

This sounds like a problem actually launching the Transterpreter. Check that the paths specified in the JEdit plugin (assuming you are using that!) are actually accessible from where you're trying to run things. If the compiling part works fine, then running things should too. Failing that, can you provide any more details? (or ask your class supervisor during one of the terminal sessions; it may be easier to diagnose the problem when it's in front of us).

Keywords: transterpreter

Question 77:

Submission reference: IN2150

Hi, I was curious as to what options were being offered after I returned from my year in industry, so had a look at the modules currently being offered. I remember someone saying that there was an advanced concurrency module and was curious as to why it's no longer running, given that the vast majority of pcs in use these days are multi core systems?

Answer 77:

Very many apologies to whoever asked this question so long ago (2 Aug 2012). We didn't know how to answer this properly. Belatedly, I (Peter) will have a go.

We've had the advanced concurrency module (Co632) prepared for several years, first presenting it in the academic year 2006-2007. Sadly, that was the only year we were allowed to offer it. The withdrawal of the Co632 option was a decision taken the the Board of Studies (now the Learning and Teaching Committee) for the School of Computing. The reason was the need to reduce the number of options offered, prompted partly by course restructuring (with more compulsory modules) and partly by falling staff numbers (voluntary redundancies). Each year, we have tried to reinstate it – without success. If anyone would like to get the Co632 materials, please contact me or Fred Barnes.

For information, next year (2012-2013) is the last year this module (Co538) will be offered. Further restructuring of the degree means that Concurrency will become part of the core (compulsory) modules, but probably spread over Stages 2 and 3. Final arrangements (timing, contents) have still to be settled. It will likely be very different from Co538.

My personal belief is that concurrency is fundamental to Computer Science and should be introduced at the same time as sequence is introduced in programming. So long as a sane concurrency model is taught, going parallel is no harder than looping and communicating between processes is no harder than assignment between variables. Start early and it will be easy.

Keywords: advanced , teaching , future

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:22 2013
This document is maintained by Fred Barnes, to whom any comments and corrections should be addressed.