|
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.
Continued from Question 120 (2004)... I'm actually working with a 2D array, although I don't think that makes any difference ? I'm not getting an error, it's a little strange but it appears to remove the byte, for example with:
log[0] := "Philxxxis eating "
log[0][5] := (BYTE n)
after this operation, "log[0]" seems to contain "Philxxis eating ". Any ideas ? I'm feeling slightly baffled.
The reason this is probably happening is because "BYTE n" is not a printable character. Casting an INT to a BYTE does not produce the character representation of the number in base-10 (decimal) -- it produces the ASCII character with the value of the integer. If you want to print out a number as its (decimal) character representation, use "out.int".
Keywords: q7
Hi, I've completed the q7 coursework but I would like to ask a question before I submit it. I found no need for the "PROC secure.college", so I removed it and did all the necessary wiring in "PROC q7". The animation still works and I feel I can understand my code better this way. Will I be marked down for the removal of "secure.college" ?
Yes, you will lose marks. There is a reason for having "secure.college" - namely structure! Discarding it leaves its innards and the "display" at the same level of network ... which is (a) more complicated and (b) illogical. Please tidy them back into a "secure.college" wrapping.
Keywords: q7
Hey I have been looking at the occam web-server (like you do ;-)) and was wondering if there are plans for any future developments ? It's looks nice and I am looking forward to having a go with it soon...
Yes, I've/we've got lots of thoughts for future development! It's just a matter of finding the time to do them.. Technical descent: Foremost, perhaps, is sorting out the socket I/O. The mechanism that does this uses OS-level threads (e.g. POSIX threads, aka "pthreads") to prevent blocking network I/O from blocking the occam system whole, but it takes a reasonable amount of time (hundreds of microseconds) to dispatch and collect these. Large numbers of connections mean lots of threads, which quickly kills performance. The solution (thought-out but not implemented quite yet) is to multiplex sockets in groups sorted by activity. In theory, there'll be one thread that goes round very quickly, one that goes round less quickly, down to one that just collects "dead" connections (where the client disappeared rather than closing the TCP socket). We're aiming for better performance than apache (obviously!), but whether or not we'll get there remains to be seen..
Keywords: web-server
Are all our seminars going to be past exam papers in occam ?
On the whole, yes, but don't let this dissuade you from attending seminars! The seminars are a good opportunity for you to fill in any gaps in your knowledge and practice some previous exam questions. But most seminar leaders will usually be prepared to cover other material, e.g. JCSP or C specific items (mailing in advance of the seminar is usually the best way).
Keywords: seminars
Could you explain the exam rubrics again ? Am I correct in thinking the questions will be the same format as in previous years (i.e. starts off with defining PROC headings and then gets us to programm more complex code) and the only difference is that we could answer all 3 and get the best marks of 2 of them?
This information is provisional, subject to approval of the rubric by the external examiner.
The Co516 paper has two parts: Section A (on the occam/JCSP material presented by Peter Welch) and Section B (on the C material presented by John Bovey). Section A carries 40 marks and Section B carries 20. There are 2 hours for the paper, so an equal time balance-per-mark between the Sections gives you 80 minutes for Section A and 40 minutes for B. The rough rule is 2 minutes per mark.
The rubric (provsional, see above) for Section A is:
Answer ANY number of questions from this section.
Full marks for this section will be obtained for correct answers to TWO questions.
If THREE questions are answered, the weakest will be given half-credit.
Marks for this section will be capped at 40.
Note: there are 3 questions in this section and each question carries 20 marks. The questions have similar styles to those asked in previous years. [Not all questions have the format of defining some PROC headers, bodies and network code!]
My (phw) advice on strategy for this section depends on how well you are on top of the material when the exam comes along. If you are on top, choose just two questions and answer them fully. The questions are designed to take about 40 minutes to be read and answered -- and you have around 80 minutes (see above). If you find yourself with any time left at the end of the examination (having checked through *all* your answers against the questions carefully, making sure you haven't mis-read anything in any question), have a go at the Section A question you haven't answered. On the other hane, if you are not on top of the material but, at least, know the basics, answer the early (easier) parts of all three Section A questions. You get full credit for the best two and half-credit for the third, which might be enough to pass. [Note: two of the questions in this Section require knowledge of occam and one requires JCSP. So, if you are skipping the JCSP material, you will have no choice of question here.]
The rubric (provsional, see above) for Section B is:
Answer the first question from this section.
Answer just one of the last two questions in this section.
Note: there are 3 questions in this section and each question carries 10 marks, making a maximum of 20 marks for this section. The first question tests basic knowledge. You must then answer only *one* of the last two questions, which test the ability to apply your basic knowledge to new problems. You may *not* answer both of the last two questions - you must choose.
Keywords: exams
Referrers: Question 134 (2004) , Question 134 (2004)
Is there any chance we could have model answers to past papers put up, or alternatively can we email you our attempts ?
Model answers to past questions are not available -- see the answer to Question 42 (2002). But yes, you may email us (specifically your seminar leader) with your attempts to get feedback.
Keywords: exams
Referrers: Question 128 (2004)
What's the point in doing CSP in Java which is virtually the same as what we've done in occam ? Is it to teach us that concurrency can be achieved in Java (an object-oriented language) as well as occam ?
See partly the answer to Question 85 (2004). The point is not to teach you that concurrency in Java is possible -- that's clearly the case already with Java's Threads. The point is to show you (and teach you) how to construct concurrent systems safely in Java. In most cases, Sun recommends that you don't use Java threads, and most people who have used them would probably recommend that too -- aliasing and race-hazard errors become a significant problem. JCSP provides a natural mechanism for concurrency (i.e. CSP), and although it doesn't remove the problem of aliasing and race-hazards completely (e.g. due to communicating references to objects, not the objects themselves), it greatly reduces the potential error. Compare, for example, two implementations of a "binary semaphore" in Java, one using Java threads (which you'll have seen in the CO501 operating-systems course, if you do that), and one using JCSP (e.g. the "fork" process from the dining philosophers, maybe scaled up to allow arbitrary numbers of connections). You'll see that the JCSP implementation is relatively simple, both in code and comprehension -- you can easily explain the JCSP "fork"-style semaphore to someone; not the case for the thread/monitor based semaphore.
Keywords: jcsp
How should question 4 (d) from the 2003 past exam paper be answered?
Not sure I can give much help here; it says "briefly explain the differences in behaviour between par.loop and loop.par.". So you should do that .. As mentioned in Question 126 (2004), you can mail your seminar leader with answers to get feedback.
Keywords: exams
Could you please tell us the examinable chapters and papers in the notes ?
See the answer to Question 105 (2004).
Keywords: exams
Just a question about the past exam papers, was there no C or occam module (under a different title) before 2001 ?
The occam course has been going for a long time.. C used also to be taught in the past (pre 1996), but as the main language, after Modula-3. Certainly in 1997, and possibly up to 2001, this course was titled "Co502: Parallel Computing and Formal Logic", consisting of the occam material plus the usual core of formal logic (sets, propositions, predicates). Just looking at the dates given in some of the dining-philosopher example programs should tell you that occam has been taught here for some time :-).
Keywords: past-exams
Referrers: Question 132 (2004)
Can you recommend a good occam compiler which I can use on Windows as I am off site and would like to practice compiling occam ? I've looked on the web and all I can find is the KRoC unix versions.
Well, you might like to try with the transterpreter version of occam. This has a free Windows version to download (and for the Apple MAC). It's a pretty full implementation of *classical* occam (i.e. the taught/examinable language). Missing for the moment is support for floating-point data types (REAL32/REAL64) and timeouts in ALT guards. Please note that this is an experimental system and work is very much 'in progress'!
Otherwise, the latest versions of KRoC/Linux work with cygwin on windows, see the answer to Question 56 (2004). Some information on the required cygwin packages can be found here.
Finally, there are probably some very old INMOS toolset compilers that work with DOS and Windows 3.1, but it's unlikely that these would be of much use to you.
Keywords: windows
In reference to Question 130 (2004), what module code was this module (or the bits in it) called and are those past papers available for extra practice ?
Previous to being CO516, it was CO502. Any available past exam papers are on the web.
Keywords: exams
I've become stuck on question (3b) (specifically producing the "rate" part) of the 2003 paper. I can't think how to make the rate process without creating a cell process, a process that links the cells and the rate process itself. But this can't be correct for only 3.5 marks. I was wondering if you could point me in the right direction.
You mean part (3c) presumably. The question hints towards the answer in this case, "The rate process maintains a buffer of the last 10 values it received, initialised to zeros". There are two ways of doing buffers in occam, serial and parallel. Both of these have been discussed in the seminars when we looked at Q6 (names+marks). The parallel approach involves some pipeline of cells, but programming in the required functionality will be messy (although not impossible). The serial approach involves arrays, and for this "rate" process, an array would seem to be the right choice.
Keywords: exams
RE the Rubric. In a previous Q you said the rubric was: (cite Question 125 (2004)). Which matches what you said in the lectures, but on the CS web page:
Parallel and Imperative Programming
There are SIX questions, THREE in Section A and THREE in Section B. Candidates should answer ANY number of questions from Section A. Full marks for this section will be obtained for correct answers to TWO questions. If THREE questions are answered, the weakest answer will be given half-credit. Marks for this section will be capped at 40. From Section B candidates should answer question 4 and EITHER question 5 or 6.
Could you please explain the format a bit clearer as you told us we would have to answer all the C Q's and either 2 Occam or 1 Occam and 1 JCSP or both occams and 1 JCSP, but I just want clarification that section A will be Occam and JCSP as previously section B was JCSP and Occam?
Nowhere in Question 125 (2004) does it say anything about needing to answer all the C questions, quite the opposite in fact. Yes, section A is occam and JCSP, section B is C -- it must be this way around given the relative marks for each section (section A carries twice as many marks as section B, reflecting the fact that twice as much time was spent teaching occam/JCSP compared with C).
Keywords: exams
With regards to question 5c of the 2003 paper: In designing the layer.b proc I have come across a problem. I have a replicated PAR and must instantiate the node.b process, however I have no idea what to use for the weight array, all I know is that "each node will be given a different array of weight values" and so cannot assume that I can include this weight array in layer.b's PROC header. Unless of course we are expected to extract each node's array from an array of arrays passed to the layer.b process from some other process, but surely that's a bit far fetched? and would also imply that any nodes above the node will have the same array. Any help would be greatly appreciated.
Passing down indices into an array of arrays given as a parameter would be quite appropriate. It's very little code in practice. "Unless of course we are expected to extract each node's array from an array of arrays passed to the layer.b process ..." -- yes, and it's not far fetched! Suppose:
PROC node.b (VAL INT id, threshold, VAL [n]INT weight,
CHAN OF BOOL up.in, down.out, right.in, left.out)
...
:
Then:
PROC layer.b (VAL INT threshold, VAL [n][n]INT weight,
[n]CHAN OF BOOL in, out)
[n]CHAN OF BOOL ring:
PAR i = 0 FOR n
node.b (i, threshold, weight[i],
in[i], out[i], ring [(i+1)\n], ring [i])
:
That's all!
Keywords: exams
2nd point, slide 57, JCSP slides: "As with occam, it's difficult to introduce race hazards." Difficult ? How can it be done, then ? :) With occam, say.
The slide, perhaps, should say something a little stronger: "JCSP Channel communication over int-carrying channels cannot introduce race hazards on shared memory". The point being, of course, that JCSP object-carrying channels *can* introduce race hazards (since only object references are sent, both the sender and receiver end up holding a reference to the same object). That point is laboured over the next few slides.
The reference to occam is because race hazards on shared memory can't happen in occam at all -- neither channel communication nor reference to globally declared memory (e.g. through reference parameters to processes running in parallel) can get us into that trouble.
It is, just, possible to compile race hazardous occam code - but only by turning off the compiler's parallel usage checks (in which case, the language being compiled isn't technically occam any more!). If you really want to do that, you should find out how for yourself ;-).
Note: occam-pi (the modern occam) has "mobile" data types, whose data is communicated by reference (like objects over JCSP channels). Even so, these communications do not introduce race hazards, since only one reference to any particular piece of "mobile" data is allowed in a system and the sender automatically loses it. So, we have the best of both the worlds described in slides 65 and 66: guarantees against race hazards and no space-time overheads for communication, ;-).
Keywords: jcsp
I've been trying to do Q1 in JCSP, but have a problem with the first suggested addition -- a freeze button.
The problem is that I don't see how to send signals down the "event" line when a button is pressed -- the closest approximation I've managed is to send a null down "event" when someone types in a character and hits return. I've introduced an "IoReader" class that implements "CSProcess", and stuck it at the other end of event from "FreezeControl". This process goes into an infinite loop wherein it blocks waiting for something to be received through "System.in", and then writes a null to event. This would be fine if typed characters were flushed immediately, but at least the default behaviour is that hitting return performs the flush.
Generally, dealing with "System.in" and "System.out" is rather un-CSP/occamly. Is there a neat way of treating them as channels (essentially what I'm trying with my "IoReader" process) ?
You're off the track here. The question says a "freeze button", not anything related to the keyboard or typing things in. You need to use a FramedButton / FramedButtonRow to get some buttons on the screen. When these are clicked they generate channel outputs (actually a string which was set earlier). To see how to use them, look at the "test" programs demonstrating them (which are located in the same directory as the source files for FramedButton/FramedButtonRow/etc. themselves):
/usr/local/courses/co516/jcsp-stuff/jcsp-coursework/framed/sources/FramedButtonTest.java /usr/local/courses/co516/jcsp-stuff/jcsp-coursework/framed/sources/FramedButtonRowTest.java /usr/local/courses/co516/jcsp-stuff/jcsp-coursework/framed/sources/FramedButtonGridTest.java
Watch out, though, that these demo programs map all the "event" channels from all the buttons through a single Any2OneChannel. That was convenient for the demonstrations, but for more interesting systems (such as Q3) the buttons should generate "event" messages down different channels.
As for System.in in Java, yes, there's no way to make it unbuffered. I tried real hard for MOSS (CO501), but it's just not possible -- it requires doing something at the OS level (in UNIX, setting various terminal settings). Java is supposed to detach from this, so you don't get to control it. I suspect setting the terminal up right before running the Java program would make it work, but it's not nice (and I don't know how Java would react to this).
Keywords: jcsp
For the voluntary questions for the JCSP ecercise 1 and 3 speak of a "FramedButton" which we "will be given". Where abouts can I get hold of these ?
You can find these on raptor under the directory:
/usr/local/courses/co516/jcsp-stuff/jcsp-coursework/framed/
On many UNIX systems, the "locate" command can help you locate files.
Keywords: jcsp
Hiya, I'm going through the JSCP voluntary excercises from the course web page, and I was wondering if there were any sample soultions, and if there aren't, would it be possible for you to put some up ?
Okay, I've copied the answers from their default home and made them readable. On raptor in:
/usr/local/courses/co516/answers/jcsp/
Multiple solution versions are given. Printing the files:
/usr/local/courses/co516/answers/jcsp/Q1/Q1-listing.txt
/usr/local/courses/co516/answers/jcsp/Q2/Q2-listing.txt
/usr/local/courses/co516/answers/jcsp/Q3/Q3-listing.txt
gives all the source codes conveniently.
Keywords: jcsp
What do you want as the answer to question 3d of 2004 exams? Is TRUE (output on the brake channel) the right answer?
No. The question asked for the sequence of outputs.
Initially, TRUE is output, since the initial value from the control logic was TRUE and the pedal channel has just delivered a TRUE. That slams on the brakes. The question scenario now syas that wheel-lock happens. This is detected by the detect process, which ourputs that fact to control, which reacts by sending FALSE to combine, which reacts by sending FALSE to the brake, which lifts the brakes.
Hopefully, with the wheels free to turn, they will start spinning again. The detect process detects this, tells control, which waits delay microseconds before outputting TRUE to combine. So long as the driver has kept the brake pedal depressed, nothing further (from the initial TRUE) has been sent down the pedal. We now have two TRUEs in combine and, so, TRUE is output to the brake channel, which re-applies the brake.
If wheel-lock re-occurs, the above sequence repeats. Eventually (and, again hopefully, before a crash), the car has slowed sufficiently for the wheels not to lock when the brakes are applied and the car stops under control.
This is a farily full description of events. Something shorter would have won full marks.
Keywords: exams
|
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. |
