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 chan-type
2011 |
Submission reference: IN2082
Hi, this is a follow-up to Question 48 (2011).
Maybe I should be a little more specific. Consider the following;
[snipped code]
[n]OCCADE.SPRITE! bundle:
SEQ
PAR --This could be replicated.
occade.start.sprite (occade, bundle[0], -1)
bundle[0][req] ! load.image; "someimage.bmp"
bundle[0][req] ! move; 20; 10; FALSE
bundle[0][req] ! visible; TRUE
PAR
occade.start.sprite (occade, bundle[1], -1)
bundle[1][req] ! load.image; "someimage.bmp"
bundle[1][req] ! move; 20; 10; FALSE
bundle[1][req] ! visible; TRUE
...
[snipped code]
Currently I have it working in a very horrible way involving the following and a lot of not replicated stuff. (it's currently not very dynamic!);
[snip]
OCCADE.SPRITE! t0,t1,t2,t3,t4: -- The "Philosophers" sat down
OCCADE.SPRITE! node0,node1,node2,node3,node4: -- ... and eating
OCCADE.SPRITE! f0,f1,f2,f3,f4: -- Forks when they are at rest
OCCADE.SPRITE! l0,l1,l2,l3,l4: -- Forks when they are left forks
OCCADE.SPRITE! r0,r1,r2,r3,r4: -- Forks when they are right forks
[snip]
The declaration of your bundle array should be:
MOBILE [n]OCCADE.SPRITE! bundle:
The latter declarations should also be arrays (which enables us to replicate code):
MOBILE [n.philosophers]OCCADE.SPRITE! t: -- The "Philosophers" sat down
MOBILE [n.philosophers]OCCADE.SPRITE! node: -- ... and eating
MOBILE [n.philosophers]OCCADE.SPRITE! f: -- Forks when they are at rest
MOBILE [n.philosophers]OCCADE.SPRITE! l: -- Forks when they are left forks
MOBILE [n.philosophers]OCCADE.SPRITE! r: -- Forks when they are right forks
But ... you haven't asked a question?
Referrers: Question 50 (2011)
Submission reference: IN2081
If you have a CHAN TYPE e.g.
CHAN TYPE TEST.a
MOBILE RECORD
CHAN TEST.a.one?:
CHAN TEST.a.two!:
CHAN TEST.a.three!:
:
Is it then possible to do the following;
PROC a ()
[1000]TEST.a! bundle:
SKIP
:
instead of;
PROC a ()
TEST.a! b1,b2,b3,...:
SKIP
:
There are syntax errors in your CHAN TYPE declaration. I'm assuming you are not wanting a recursive channel type (i.e. one that can carry its own channel-type-ends in some of its channel fields – although this is possible)? A syntax-legal declaration is:
PROTOCOL TEST.a IS INT: -- say
CHAN TYPE TEST
MOBILE RECORD
CHAN TEST.a one?:
CHAN TEST.a two!:
CHAN TEST.a three!:
:
We can declare an array of channel-type-ends ... but because only MOBILE channel types are currently allowed, such an array must also be declared MOBILE.
However, there is no point declaring an array of just one end of a channel type – we need two arrays: one for each end. Further, declaring channel-type end variables (or arrays) does not construct the channel bundles. As in Java, this is done dynamically:
VAL INT N.SERVERS IS 1000:
PROC a ()
MOBILE [N.SERVERS]TEST? bundle.server: -- elements not initialised
MOBILE [N.SERVERS]SHARED TEST! bundle.client: -- elements not initialised
SEQ
SEQ i = 0 FOR N.SERVERS
bundle.client[i], bundle.server[i] := MOBILE TEST -- construct a channel bundle
-- all elements of both bundle arrays are now initialised
--
-- the number of channel bundles constructed is N.SERVERS
--
-- for each i, bundle.client[i] and bundle.server[i] hold
-- opposite ends of the same channel bundle
--
-- for each i, any number of (client) processes may share
-- use of bundle.client[i] (because it's SHARED)
--
-- for each i, only one (server) process may be given and
-- use bundle.server[i] (because it's not SHARED)
... etc.
:
Now we can give each bundle.server[i] to its own server process and each bundle.client[i] to as many client processes (for the server at the other end) as we like.
Note: the client end array was declared to hold SHARED ends only because that is a common paradigm. Neither end need be shared ... or both can be shared ... or just the server side.
Note: the material on MOBILE data and channel types is not an examinable part of this course module.
Keywords: chan-type
Referrers: Question 49 (2011)
Submission reference: IN2064
Hi, is is possible to have channels, both shared and normal in a RECORD? I have this:
CHAN TYPE foo
MOBILE RECORD
CHAN INT x?:
CHAN INT y?:
:
but this doesn't compile when used with SHARED CHANs. Is there a way of doing this, or do I just need to pass the SHARED CHANs individually, as it doesn't seem possible to have an array of them either?
Fields of a CHAN TYPE RECORD (informally known as channel bundles) can only be CHANs (with field names that specfify the direction of use) – so the direct answer to your question is: no. However, ...
We only declare variables for the ends of such bundles of channels. The type names of these ends are the type names of the bundles, Bundle type ends with the "!" specifier mean that their channel fields must be used in the opposite directions to those declared in the bundle type (they are the opposite ends of the bundle). Note: it's the the type of the bundle ends that carry the "?" or "!" specifiers – not the variables that hold them (whereas, for standard CHANs, direction specifiers go with the channel variables; we apologise for this inconsistency).
Now, bundle type ends (i.e. either end of the whole bundle) may be SHARED, which should give you what you were after (I hope). Many processes may be given the same end of a shared bundle of channels. To use them, just CLAIM the bundle-end variable and use the individual channels as you like (in the correct directions, of course). See the Mobiles slides 39-43 for examples.
Note: the material on these these channel bundles is not an examinable part of this module.
Re. your question about arrays of shared channels (ordinary ones): sorry, these are not supported – see Question 30 (2010). However, arrays of shared ends of channel bundles are supported, :).
Keywords: shared-channel , chan-type
|
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. |