CO631 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 polling
2004 |
I'm now somewhat through Q4 and have noticed that I'm using polling `PRI ALT's. It says in the coures notes that they should be used only as a last result -- I'm wondering if this is acceptable in Q4?
I'm not sure of another way of interupting a process based on a signal that may or may not arrive. I've created PRI ALTs in the new control PROCs that have been added to `numbers', `integrate' & `pairs'. I'm now planning on using it to react to the byte `s'
As the course notes say, polling should only be used as a last resort. I wonder, however, if you're actually polling.. Polling code is specifically this:
PRI ALT c ? x ... do something with `x' TRUE & SKIP -- skip guard SKIP -- do nothing
When executed, if data is available on the `c' channel (i.e. the corresponding outputting process is blocked in the output), then that data will be accepted immediately (placed in `x') and the guarded process runs. If data is not available on the `c' channel, the `SKIP' guard is selected and does nothing -- so the `PRI ALT' finishes immediately.
That code is polling, and it can create problems.. For example:
WHILE TRUE PRI ALT c ? x ... do something with `x' TRUE & SKIP SKIP
This code will consume as much CPU as it can until some data arrives on the channel `c'. Of course, the correct code in this case (since the process does not interact with anything else in the loop) would be:
WHILE TRUE SEQ c ? x ... do something with `x'
This code, on the other hand, will wait for something to arrive on `c' then do something with the data received. And waiting (either blocked on channel communication or waiting for a timeout with `AFTER') does not consume the CPU. (although busy-wait versions of these could be created easily, it would be daft..).
It's the `SKIP' guard in the `PRI ALT' (and subsequent do-nothing process or do-very-little process) that constitutes polling.
The following code, for example, is not strictly polling (but it is not nice code):
WHILE TRUE PRI ALT c ? x ... do something with `x' TRUE & SKIP SEQ d ? y ... do something with `y'
If you've written stuff like that, you probably wanted instead to write:
WHILE TRUE PRI ALT c ? x ... do something with `x' d ? y ... do something with `y'
These two code fragments do not behave in the same way, however. The first will commit to input on `d' if `c' is not ready -- refusing then to service `c' until something has arrived on `d'. The second will happily wait for both, and service the first channel that becomes ready (or `c' in preferance to `d' if both are ready).
You can read some more on ALTs and polling in this occam tutorial.
2002 |
Is it possible to take input from a channel un-synchronised? For example, you want to listen for input on the keyboard, but do not wish to hold up the process if a key is not pressed.
Un-synchronised is not the right word. What you describe is polling the channel to see if input is available from it. If none is available, you would like to be able to do something else and - usually - try again later.
Warning: writing such polling loops is usually the result of bad design. For occam, it's usually simpler to leave a process blocked waiting for input and have another process, running in parallel with it, do that something-else work.
However, if you really need to poll a channel to see if input is available, see slide 5-37. But you will have to study the earlier slides on the ALT construct (and read section 4.3 of the `occam2 Checklist' paper) first to understand it.
Keywords: polling
Last modified Mon May 15 17:39:46 2006
|