|
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 occam
2011 |
Submission reference: IN2061
Hello there, I am wondering; is it possible to use an id-like process to link two channels of the same protocol without having to read the data from the protocol by yourself and re-send it along?
Connecting two (same-protocol) channels with an id-like process yields a buffered channel with capacity 1. The CSP library for Java (JCSP) provides for the construction of occam-like (i.e. unbuffered) channels by default, but also for buffered channels of any capacity (including infinite) and varying kinds of buffering (blocking, like Choices slide 105, overflowing, slide 107, or overwriting, slide 108). At some time, it would probably be good to introduce this into occam-pi – it would be more convenient, safer and more efficient for the compiler to construct such buffering than the programmer.
A second point raised by your question is that of generics. It would be nice to be able to parametrise the types of messages carried by channels plugged in to processes that don't care. For example:
PROC id <TYPE P> (CHAN P in?, out!)
WHILE TRUE
P m:
SEQ
in ? m
out ! m
:
Instances of such a generic process would have the obvious form – e.g.
id <REAL64> (a?, b!)
which would instance an id process for channels carrying double-precision floating-point numbers.
However, defining the above idea is complicated by the current concept of message PROTOCOLs in occam-pi (see the Protocol slides, not yet covered in the course). It should probably wait for a more powerful type system for occam-pi (that is planned).
You are also asking, I think, for a syntactic sugaring that saves "having to read the data from the protocol by yourself and re-send it along"? Perhaps, something like:
PROC id <TYPE P> (CHAN P in?, out!)
WHILE TRUE
out ! (in ?)
:
or maybe:
PROC id <TYPE P> (CHAN P in?, out!)
WHILE TRUE
in? > out!
:
It's a thought! See also Question 56 (2010).
However, for all forms of engineering (such as language design), always consider Occam's Razor: "Numquam ponenda est pluralitas sine necessitate", which roughly translates to "Don't invent things you don't need" or "keep it as simple as possible". For programming languages, this means only adding mechanisms that are really needed ... where real need covers new ideas (that let us do useful things we couldn't do before) and more powerful forms of expression (that let us do common things more easily than we did before). We have to work hard to honour this principle. Software engineering constructs virtual artifacts – unconstrained by limits imposed by the physical world. As such, it's only too easy to build something complex that doesn't quite do the job ... than something simple that does.
Keywords: generics , protocol , occam , razor
2004 |
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
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)
|
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. |
