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.
In "PROC q6" shouldn't "display" be wired to "(b, screen)" rather than "(a, screen)" ? well, according to the diagram anyway.
It should, yes, but you need to create "PROC collate.marks" and modify the code in "PROC q6" such that it matches the diagram. What goes inside "collate.marks" is up to you (but see the text in q6.occ).
The "q6" code body, given in the starter source code file, wires "read.data" directly to "display" -- you have to change that! The starter file was coded that way since it gives you something that is immediatley compileable and runnable on the test data files (although, of course, it won't produce the right results).
Keywords: q6
Should our program work over "nn_data.txt" or "small_results.txt" or both ?
Three test data files are provided in your exercises directory:
nn_tiny.txt nn_small.txt nn_data.txt
Your program should work over any of these files. The file "small_results.txt" is the result file produced from running my model answer on the "nn_small.txt" test data file. It's given so you can compare your results with mine. It has, of course, entirely the wrong format for an input data file for your program! The read.data process will handle it by simply outputting one poison message and terminating. So, actually, it would be a good test of your code to try using it that way! Your program should simplt terminate, after the display process has output its initial headings.
Keywords: q6
I have modified my code below:
PROC sort.cell (CHAN OF NAME.NUMBER in, out) ... process body :
What I'm trying to do is grab the first name and store it in the "stored" variables, then go into a loop getting the other names, and comparing the name to "stored.name", and if it is equal it increases the stored mark, or it sends the name through the channel ("out"); if a "poison" is given it sets "ok" to false and sends the stored variables. It compiles fine but deadlocks when it runs.
I was wondering if the problem is in my "collate.marks" (I implemented it almost exactly how "sort.pump" was done) see below:
PROC collate.marks (CHAN OF NAME.NUMBER in, out) [max.diff.names] CHAN OF NAME.NUMBER c: PAR ... sort.cell processes :
Please help! I feel like I am cracking it but I have no real idea of where the problem is or why it isn't working!
These sort of questions are better targetted at your seminar leader -- since we can't post your solution on-line! The code is very nearly correct, except for one small thing. If you look at the sort-pump code, you'll see that each cell outputs its version of "poison" when it receives it. In your sort cells, receipt of "poison" triggers the output of the stored name, but the "poison" is never passed along! (so the next cell sees some incoming name, which it deals with, but no poison).
Keywords: q6
vim question: how does one indent multiple lines at once ?
From command mode, use "shift + V" to start `visual line'. Move the cursor to the end of the block you want to indent, then "shift + >" to indent. You can repeat the indent with "." (as you can repeat any other command).
If you're using the Kent Vim extensions and GVim:
Select relevant lines. Indent with "tab" or "alt + right-arrow". Outdent with "shift + tab" or "alt + left". This also works for the current line (without having selected it). Exception: in insert mode "tab" inserts a "tab" (as expected). In normal mode or if text is selected, "tab" indents. The other shortcuts work in any case.
occam. Why?
As if Haskell wasn't obscure enough, what made the department decide that it would be worthwhile to teach students a language that has been dead for some time. CS is a fast moving field to say the least - shouldn't we be learning new technologies ?
I can appreciate the need to teach concepts of parallelism, and that Java's threads model is a bit of a mess. However, it's a widely used mess, which as far as I'm aware, occam's model is not. At the very least, it would strike me as more logical to expend all this time on JCSP rather than occam: the same fundamental concepts, but in a widely used language.
(Sorry if the tone of this seems overly negative... I've had far, far too little sleep in the last couple of days)
You are in need of some convincing :-).
Firstly, occam is not a dead language! It's true that what we teach in CO516 is based on something that happened several years ago (i.e. occam2.5), but the occam language has come quite some way since then. We now have something called occam-pi, that supports a whole new level of dynamic behaviour (e.g. dynamically reconfiguring process networks using mobile channels and mobile processes -- with mobile data thrown in as well). The reason for not teaching you this is because we can't, until we get a version of the new KRoC system (that shows itself as KRoC/Linux and KRoC/cygwin) for Solaris (raptor, etc.). If the department were willing to support a sufficiently powerful multi-user (i386-based) Linux machine, we'd use that and the new KRoC instead. Time is at a premium, however. We have just been funded for a Gbit-switched cluster of machines to investigate rules for the safe construction of massively parallel nanite assemblies ('nanobots'). We need to be able to model around 10 million of these (initially). occam-pi is the only technology currently available for the job. If the funding bodies think it's worth something, then it's certainly not dead!
The reason for learning occam is not to teach you occam per se, but to teach you about the underlying concepts of this parallel programming model. The model in this case is something called CSP -- Hoare's "Communicating Sequential Processes" (occam-pi also takes elements from Milner's pi-calculus, for mobility and dynamism). occam is a very clean implementation of the CSP technology. JCSP, although very useful, is not as clean (because it's built on Java). In occam, you cannot write a program that has race-hazard or aliasing errors. The compiler performs rigorous analysis to ensure that your code is free from such problems. For JCSP, we can't do this (well, not without building extensive tools on top of Java and, even then, it's far from certain that this is possible). The threads and locks model of Java is not policeable and very difficult to use correctly -- JCSP provides much better concurrency control, but we still can't verify that its usage is correct -- i.e. you can still write programs with massive aliasing and race-hazard errors in JCSP. Although design-rules exist to avoid these, programmers may be tempted to "shortcut" and end up creating problems -- that's just not possible with occam-pi. Also, when you start using third-party or add-on code that itself employs threads and locks, you end up with a system whose behaviour you can no longer reason about. With occam you simply can't cheat (unless you start turning the compiler checks off, which isn't recommended and the result is not real occam).
Being able to reason about the behaviour of a system is crucially important. Frequently the news contains stories about massive computer failure ... and we are all too familiar with PC applications, or even the whole operating system, locking up and reboots forced. Why? Well, because they didn't design the system properly, and didn't use a language that has safety guarantees. Knowing that a system has failed at run-time is not always useful (e.g. if the space-rocket or aeroplane is already careering towards the ground). We want to analyse these things in advance, at the design stage. This you can do in occam (either by proof-techniques on the code, or by refinements in the underlying CSP design before you write any code). Try proving (formally) that a Java program implements some specification -- you can't, it's as simple as that. There are no formal semantics specified for Java (nor for any of the common mass-used languages). So far as Java concurrency is concerned, we have developed a formal CSP model of all its mechanisms (i.e. synchronized, wait, notify, notifyAll, ...), which we have used to verify the correctness of our JCSP implementation. However, for general use, the aliasing endemic in object-oriented programming makes analysis of large-scale concurrent systems infeasible. In JCSP, that's kept under control within the Channel/Alt/Par mecahnisms. People are still trying to build a formal model of the C language, and Java is significantly more complex than C! occam is a language built directly on top of a formal model. It is therefore, arguably, a much better language and is certainly a proper choice for university level courses ... where we are teaching ideas much more than we are training you for specific skills. However, the specific skills you will learn from studying and using occam (and JCSP) will stand you in very good stead whenever you have to deal with concurrency, at whatever level of granularity you have to deal with it (e.g. as a chip designer or networked game implementor), whether you are a designer, implementor, maintainer, formal verifier or tester ... and whatever concurrency technology you are obliged to use (especially if it is based on a model that is older than the one burnt into occam ... such as the ones burnt into Java and Posix Threads!).
Another reason for using occam is its performance. We can quite happily write a system containing 1 million processes (threads if you like). And such a system will do useful work in useful time (the channel communication time of KRoC is around 70 nano-seconds on a P4-3.4-GHz, even with a million processes being scheduled and a guaranteed cache-miss each time any of them runs). Even with a thousand times less processes, Java/JCSP (or Java/threads-n-locks or C/Posix-threads) will struggle to keep going.
We could go on, but hopefully this gives you some idea of why occam is far from dead, and very much an important technology for the future. occam/CSP also give us things like compositionality and scalability (which object-orientation does not) -- you can build a really big system with linear complexity (i.e. the cost of modifying/extending the system depends only on the size of the modification/extension, not on the size of the system being modified/extended). Forget it in Java/etc.. Aliasing tie-ins bind different parts of the system together that break information hiding. We have to work very hard indeed to keep this under control ... and, as the system grows in scale, it's a losing battle. We just end up with a broken system that's too complex for anyone to understand ... exemplified by the number of massively expensive industrial failures. On the other hand, the occam language is very simple, can be learned very quickly (the principle of Occam's Razor applies) and, once mastered, is easy to use and scales.
Finally, the classical occam we are teaching is the basis of the modern occam-pi, which is absolutely a new technology. The CSP/pi-calculus ideas burnt into occam-pi are enabled for Java through the JCSP package library, though with significantly reduced safety levels and performance. We teach occam first because its syntax matches (and was designed to match) the concepts exactly. As you will see when we study JCSP next term, the Java API requires a fair amount of syntactic baggage that is a little distracting from the core message.
[History: object orientation was first described in the late 1960s, going into real use in the 1980s and into widespread use in the mid-1990s. Monitors were developed in the early 1970s and not used very much till the Java phenomenon of the mid-1990s. It takes that long for new technical ideas in CS to move from discovery into practice. CSP was first presented in 1978 and revised in 1985 and 1996; research and application (e.g. for proving the correctness of secure networks and smart-cards) is extremly vigorous. The pi-calculus appeared in 1992 and has been in continuous development ever since -- applications in the design of distributed systems that cope with failure, business modelling etc.]
[More history: classical occam was designed and implemented by Inmos from 1981-1992. Since then, what has now become occam-pi was developed (and is being developed) in this department. JCSP has been (and is being) developed since 1996, also within this department.]
Referrers: Question 127 (2004)
Will we get seminars in C next term or are we meant to study C ourselves ?
No, there will not be any specific seminars on C, but the occam seminars will continue until the end of term. In previous years some seminar leaders have spent time looking at C, usually in response to specific questions. Things will likely be the same this year.
I was wondering that if we don't submit q6 before 4pm this afternoon, would it still be ok to submit it tomorrow ? As I might need more time to implement it.
The deadline is 4pm today (and this may be so that CAS can get the marking to us before the university closes). In the past we've operated a sliding-scale penalty for late submissions, where the penalty reaches 100% after 7 days; this will apply. Late submissions should be emailed directly to your seminar leader.
Please note that the model solutions will be made readable tomorrow, so that students may have something to read over the vacation, :). If you are submitting late, do not read the model solutions first (we can tell!).
Keywords: q6
What other programming langauges are classes as parallel ones ? Just trying to see what other languages we may come across in industry which have the same style/syntactic layout.
Also why does this module cover occam (a parallel language) and C (a procedural one) covered under the umbrella parallel and imperative programming?
Very few languages fall cleanly into the category of "parallel" languages. Ada and Erlang are, perhaps, two of the others. Most languages do not address concurrency at the language level -- only through add-ons provided by libraries (whose semantics are 'magic' in the sense that those libraries cannot be implemented by the languages they are supporting). Java (mostly) falls into this category -- apart from its synchronised keyword, the essential concurrency mechanisms are provided by apparently normal methods (Object.wait, Object.notify, etc.) from the java.lang package library. There are a couple of scripting languages that are very loosely based on CSP (e.g. Lingo), but whether you could classify these as "parallel" is debateable.
As for the module title: occam is a parallel language and an imperative and a procedural language; C is an imperative and procedural language. They are imperative because they have variables and assignment statements. They are procedural because we can abstract sections of (imperative) code into procedures with a call/return semantics. Java is also imperative and procedural, but is also object-oriented (which, of course, occam and C are not). occam, however, is process-oriented (which Java and C are not not -- at least, they are not so at the langauge level ... through libraries, like JCSP/CCSP, they can be operated in a parallel and process-oriented way). C++ is imperative, procedural and object-oriented (and can also be operated parallel and process-oriented through libraries such as C++CSP).
The reason the Co516 module combines the "Parallel" (occam/JCSP) and "Imperative" (C) parts is for logistical convenience. We want to teach both topics in year 2. Their sizes add up to the size of one module ... so they were put together. There is no logical reason for having them together. Indeed, the revised Stage 2 programme starting next year breaks them apart.
Keywords: occam
Have we covered enough material to start the dining philosophers this holidays ?
Also are there any useful areas we can start to look at for revision (in terms of website with practice questions on what we've covered so far?)
The dining philosophers have been covered in the lecture, so yes, you could in theory make a start on this. But we'll be looking at this in more detail (e.g. ways of doing animations, etc.) in the seminars next year.
For revision material: the course notes (including the various papers on occam); Fred's occam tutorial; and past exam questions. But these are all obvious..! You should be able to decide for yourself whether something in a (past exam) question has been covered or not. Your own lecture notes may also be useful to this end.
Keywords: q7
I know this is rather late, but is there any chance you could put a version of the terminal-session work (as in the question sheet from the course notes) and occam two checklist (basically all the things from the printed notes which aren't currently accessed by the co516 webpage or raptor) either on raptor or the module webpage, as I am flying home today but don't have room for your book but intend to do some occam this holiday ?
The questions and occam2 checklist are already on raptor!:
/usr/local/courses/co516/etc/ex-sheet.pdf /usr/local/courses/co516/etc/checklist.pdf
Both of these are also in the same directory as postscript files, and the checklist additionally as text.
The course notes themselves are not on-line, but some of the related occam/Java/CSP papers are (in that same directory). The occam tutorial may be useful.
Is John Bovey going to have a separate anonymous Q+A page for C ?
No, there will not be a separate anonymous question page for C. If you have questions regarding the C part of the course email John Bovey directly.
You can always chance your C questions here, and we might answer them..
You said "You can always chance your C questions here, and we might answer them..". Could you explain the difference between using & and &&?
These are the same (more or less) as they are in Java. "&" is bit-wise "and" (e.g. each bit in the output is the "and" of its corresponding input bits); "&&" is a logical "and" (e.g. a boolean operator).
The single ampersand "&" is also used as the "address-of" operator in C (monadic operator), as well as bit-wise "and" (diadic operator).
The double ampersand "&&" (logical-and) also behaves as a sort of "shortcut" operator (although terms for this may vary). Essentially if you write:
if ((p != NULL) && p->stuff) { ... stuff }
Then the right-hand-side of the && will not be evaluated unless the left-hand-side evaluated to "true". Thus, the above works -- you can only dereference "p" if it isn't NULL, that the left-hand-side checks for. If you wrote it the other way around:
if (p->stuff && (p != NULL)) { ... stuff }
This would crash if "p" was NULL.
Note that this is not special to C -- Java does it as well. For example:
if ((obj != null) && obj.needs_processing()) { obj.do_processing (); }
In the occam exam I am presuming we'll have to write some code ? Will the marking scheme be lenient-ish in marking since occam has strict rules on indenting ? Also will we be getting some practice in this later on in the terminal sessions ?
You may have to write some code in the exam (and based on past exams it's probably quite likely). The marking will be lenient in the sense that we won't be expecting exactly 2 spaces, but the indents and outdents (where they occur) should be obvious. If you do write some code, then realise the indentation is wrong, don't re-write it (that'll take too long). Instead just draw suitable annotations to show the indentation change.
For practice, we will be looking at some past exam questions in the seminars -- terminal sessions finished long ago for this course!
Keywords: exams , indentation
I thought we were supposed to have already had the C assesment set last friday. What is going on?
Sorry -- that was our mistake. This year, the C assessment will be set in week 17 (not week 14, which was far too early!). The submission date remains the Thursday in week 22, which gives you (almost) 5 weeks and will be more than sufficient.
Aside: the final occam assessment (on animating the Dining Philosophers) has had its submission deadline put back to Monday in week 18. This has been announced in the lectures and seminar groups.
The Co516 "Assessments" web page will (eventually) be updated to reflect these changes. This may take several days.
There seems to be some conflicting deadlines for Q7 ? On the Student Portal it says:
CO516 Parallel and Imperative Programming A4 DINING PHILOSOPHERS ANIMATION Mon, Wk 18 Tue, Wk 3 phw Mon, Wk 21 Reception
on the co516 webpage it says:
ASSESS 4 A4 DINING PHILOSOPHERS ANIMATION 60 32 3 Tuesday 17 Thursday
and my seminar leader says the 14th Feb is the deadline. Which of the above is the correct deadline?
Monday of week 18 (14th February) is the actual deadline, as we have been telling you in the seminar groups. So it's the webpage that's wrong. The data that appears under "assessments", etc. is not current -- we're not allowed to pull data from the live student database so stuff there will always lag behind the real student database.
Keywords: q7
Do we put the "VAL INT id" call inside the "PROC" header for philosopher and fork, or is this done in the main body of the "PROC" ? I think it is the former, but I'm not sure how to replicate this in "secure.college".
Be careful of your terminology -- "VAL INT id" would either be a parameter or abbreviation (that latter which you're unlikely to be using). It's not a "call" of any kind.
You are correct in thinking it should be in the PROC header for the philosopher, but what the PROC gets is a value (the "VAL" bit), not a variable. The replication in "secure.college" is already done for you -- you just need to "plug-in" the desired value (that should be fairly obvious if you look around, or compare the code with the network diagram for it). Also, looking at previous questions relating to q7 (particularly for previous years) will tell you the answer.
Keywords: q7
This is the error that came up when I tried to run my code:
KROC: Floating-point error KROC: Fatal error code 42, core dumped Abort (core dumped)
Can you tell me what it means ?
It means there was a floating point error.. If you've got access to the Linux (or cygwin) version of KRoC, compile with the "-d" flag (debugging) and it'll give you some useful information. Floating-point errors include: divide-by-zero, overflow, underflow, denormalised-operand and inexact-result. Chances are it's divide-by-zero (or modulo-by-zero).
Keywords: floating-point
Can I check that "!" is an input and "?" is an output ?
In fact it's the other way around, but finding this out for yourself should be easy! Look at the occam-2 checklist (in the course-notes and on raptor in "/usr/local/courses/co516/etc/").
Keywords: channels
Why in "PROC philsopher (...)", do you have:
PAR -- pick up left ! TRUE -- forks right ! TRUE ... eat PAR -- put down left ! TRUE -- forks right ! TRUE
i.e. why is the code the same for pick up and putting down the forks ?
The reason is simply that it requires less channels. Extra channels could be added for the putting-fork-down events, but it's better if we can re-use the existing channels (less coding and less plumbing on the network diagram). The same reasoning applies to the fork process -- adding extra channels is possible, but unnecessary.
The direction of communication along the left and right channels is important to the fork process. That has to choose (i.e. ALT) between competing signals from its adjacent philosopher processes, who might be trying to pick it up. That signal is represented by a channel communication. We can only ALT between input communications, so the forks must input and the philosophers must output. This is for picking up the forks.
For putting down the forks, neither side needs to ALT ... so the direction of the communication, signalling this event, doesn't matter. So, the fork could output to the philosopher who picked it up (and be blocked until that philosopher did a corresponding input to indicate that it was putting down the fork). But, then, we would need another channel (a putting-down-channel) between each philosopher and fork - since channels may be used in one direction only and we are forced to use the existing ones in the other direction. So, the simplest thing is to reuse the existing channels and get the fork to input from it (and be blocked until the philospher holding it does an output to indicate that it was putting down the fork) ... which is what happens.
Note that we do use different channels between each philosopher and the security guard to represent the let-me-in-to-the-dining-room and let-me-out signals. The security has to ALT between all of these, so the direction of communication has to be from the philosophers to security. The security has to ALT both for the let-me-in and let-me-out signals, unlike the fork (which only has to ALT for the pick-up signals). But the security has also to refuse further let-me-in signals -- if four are already in -- whilst allowing let-me-outs! Doing that trick with only one channel used for both let-me-in and let-me-out signals is hard. So, we used separate channels.
Keywords: q7
Where can we get help on how text (ASCII characters) are laid out on a screen ?
This has been covered (or for Friday groups, will shortly be covered) in your seminars. However, there is plenty of information in past questions. E.g. the questions related to animation.
Keywords: output
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. |