XML 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 jcsp

Question 154 (2004):

Just a quick question about the 2003 past paper. In relation to the JCSP question (q6, part b) on the Merge2 Process, should we be reading in from both the channels in Parallel or ALT over them taking input from whatever one is ready?

I would have thought ALTing seemed best, but the channels given to Merge2 aren't ALTing ones - just standard ChannelInputInts which (as I understand it) you cannot ALT over?

Answer 154:

You are right - you cannot ALT over a ChannelInputInt. You need AltingChannelInputInts for ALT guards. But Merge2 should be programmed without ALTing on its input channels and without reading from them in Parallel!

Before entering the loop, read one number from each input channel - in SEQence, any order.

At the start of the loop, the invariant is that we have the latest number from each input channel that has not yet been output. Look for the smaller one and output it, followed by reading another number from the channel that had supplied that smaller number (which re-establishes the loop invariant) - end-of-loop. Exception: if both numbers are equal, output either of them (just the once!), follwed by reading a new number from each channel (again, in SEQence, any order) ... re-establishing the loop invariant ... end-of-loop.

Keywords: exams , jcsp

Question 151 (2004):

When writing the final class in JCSP, e.g. in the folder Q2 (from the course directory on raptor), the class Q2 has a main() method and does not implement CSProcess. Is this always the case ?

Answer 151:

If it is the "top-level process", then yes; in this case, Q2 is the top-level process (i.e. the overall application/program).

A class should implement CSProcess if something is going to run() it. That might be directly, or indirectly as an embedded process within a Parallel (which is itself, of course, a CSProcess). JCSP processes can be fired up from many sources - e.g. Java applets or applications. In this case, Q2 is a Java application and execution starts from main(...).

You will not be troubled by such considerations in the exam!

Keywords: exams , jcsp

Question 139 (2004):

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 ?

Answer 139:

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

Question 138 (2004):

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 ?

Answer 138:

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

Question 137 (2004):

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) ?

Answer 137:

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

Question 136 (2004):

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.

Answer 136:

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

Question 127 (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 ?

Answer 127:

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

Question 40 (2002):

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

Question 32 (2002):

[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 94 (2000):

Re. the 2000 exam paper question 6(h). Have we covered the double buffering required to prevent the breaking of parallel usage rules with Java objects? If you could point me in the right direction, it'd be appreciated.

Answer 94:

Double buffering is a simple idea. The sender process declares two objects of the type that it's going to output - these are the "buffers". In each loop, it sets up one of them and sends it. It switches between which object to use after each loop - the first loop it uses object 1, the second loop it uses object 2, the third loop it uses object 1 again, the fourth time it uses object 2 again etc.

The receiving process need not be aware of these switches. In each cycle, it just inputs an object, processes it and forgets about it. [For example, the B process of part (g) needs no change.]

Now, when the sender is working on obect 2, the receiver will be working on object 1 - and vice-versa. Each process is always working on different objects and there is no race hazard. The switching between which object to use is synchronised by the (once-per-cycle) channel communication.

That's all there is to it. For information on its use in anger, see the (javadoc) documentation on:

  jcsp.plugNplay.ints.ParaplexInt

and:

  jcsp.lang.parallel  (the "High Level" and "Low Level" examples)

Keywords: double-buffering , jcsp