CO538 Anonymous Questions and Answers Keyword Index |
This page provides a keyword index to questions and answers. Clicking on a keyword will take you to a page containing all questions and answers for that keyword, grouped by year.
To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.
Keyword reference for process-networks
2003 |
I'm having some problems with the new pairs process. This is what I've done:
[snip code]
It doesn't seem to be doing anything. Any suggestion ?
This appears to be a common mistake -- you're instancing the `plus' and `minus' PROCs from inside another component, that results in your component behaving like either `plus' or `minus' respectively. However, once called, these PROCs never return, as they have WHILE TRUE loops.
If you want a single component to take care of the addition/subtraction, you have to engineer (program) it that way -- i.e. a single self-contained PROC, not one that instances other PROCs. If you do want to re-use the existing `plus' and `minus' PROCs, they have to be engineered into a suitable parallel network -- i.e. instanced directly under a PAR, not from sequential code.
Keywords: q4 , process-networks
Referrers: Question 29 (2003)
Hi, i'm trying to implement the second part of q4, where the inputs `n' and `i' have an effect on the operation of the program.
I have defined a `monitor' process which outputs 1 to a chan, depending on what the keystroke is:
PROC monitor ([]CHAN OF INT out, CHAN OF BYTE keyboard, intr) --{{{ forever WHILE TRUE ... wait for `intr' and process accordingly --}}} :
When trying to implement my version of `numbers', I wanted to continue using the numbers as normal, but if the INT 1 came in through a `control' chan, to set the value of the input to the prefix as 0 (hence starting it from the beginning again)
PROC my.numbers (CHAN OF INT out, control) CHAN OF INT a, b, c: WHILE TRUE PRI ALT INT x: control ? x IF x = 1 c := 0 TRUE PAR delta(a, out, b) succ(b, c) prefix(0, c, a) :
However, it doesn't work. Any help ? :)
As regards numbers, you can't do what you're trying to do with the above code. The compiler will reject it at the ``c := 0'' line, since you can't assign to a channel. We'll assume you meant to output instead, `c ! 0'.
The compiler won't reject that code (if fixed), but it won't work either. Initially `my.numbers' will wait for a signal on the `control' channel -- and won't output anything.
You'll notice this immediately, and maybe press the `n' key to prod `my.numbers'. Given this, the ALT will wake up and run the IF process. Given that `x' will be 1, `my.numbers' will attempt to output on the `c' channel, and deadlock -- there isn't anything connected to the other side of that channel. If, for some reason, `x' was not 1, the original `numbers' process network is run (by the PAR). That'll happily output numbers forever and ignore the `control' channel, such that an attempt by `monitor' to communicate will cause deadlock (in `monitor' as it attempts to output).
You actually need to modify the original process network for this one, as will be explained in the seminars this week (if it hasn't already). To do this, you need to understand what happens when the `numbers' network is switched-on; essentially a number `flows' round in the loop, being incremented by `succ' each time, with `delta' producing the copy that is output. Thus, to reset the numbers back to zero, you need to interfere with that `flow'.
In occam, you can't interfere with a process externally -- the compiler just won't let you (unless you forcefully turn the checking off, but this is rarely a good thing). Attempts to communicate `externally' on the `c' channel (and in parallel), will be banned by the compiler. The modification needs to be `deeper'.
Note: Eerke has mentioned that the deadline for Q4 has been moved back one week, into project week. From the ukc.cs.cs2 newsgroup:
This also reduces the deadline bunching in week 8: the minor pieces of coursework are still there, the major one for CO516 is now the single deadline in week 9.
.. so you've got a bit more time on this.
Keywords: q4 , process-networks
2000 |
I am having some trouble with part 3 of the assessment. Here's my code:
... censored
What I'm trying to do is pass through a channel of INTs, multiplying them by a factor, whilst in parallel checking another channel to see if the monitor has passed a zero and, if so, changing the factor.
The problem is that KRoC won't complile the code because it won't let me read and write to a variable in parallel - which is fair enough 'cause I could see some problem arising if they both want access to it at the same time.
Is there a way to get round this, or do I need to rethink my ideas?
I haven't shown the code because it's wrong in too many ways, I'm afraid, and posting it would not help anyone.
It's not KRoC that won't compile it so much as the language doesn't allow it (and, therefore, KRoC rejects it). We are simply not allowed to look at a variable in parallel with another process that's changing it. So, you do need to rethink your ideas. Check out Question 44 (2000) and its answer.
Keywords: q4 , process-networks
Having missed the lecture, I can't understand the operation of the nos, int and pairs networks. I can't match them to te sequential version. Some help, please?
I'm afraid these pages are for more specific questions than this - not to repeat the lecture notes. Please get to the lectures because things get explained there that might not be obvious from just looking at the course slides. However, nos and int, at least, are discussed in the Occam Approach to Transputer Engineering paper in the course book ... and you are also talking about these things in your seminar groups.
Keywords: legoland , process-networks
Is PAR used *only* when connecting all PROCs to build the final one big PROC?
No. See the above answer for an example use of PAR to build some very fine-grained parallel code. It all depends on the code you write into the components of the PAR. In the above, they are short-lived primitives (a channel input and an assigment). If the statements controlled by the PAR and instances of PROC calls and those PROCs are long-lived (e.g. they contain loops - possibly infinite), then we get a long-lived process network. See, for example, slide 4-26 from the course notes. [BTW - has everyone found the deliberate mistake on slide 4-26?]
occam lets us easilly build parallelism at any level in the system - this is much more flexible than Java, for example, whose Thread mechanism is considerably more complex to set up.
Keywords: par , process-networks
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. |