[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JCSP - Interpreter (& too restricted visibility of classes in JCSP package)

Hi Neil,
Thats it exactly. As for the extensibility, it really depends where you look. Some classes are exposed rather dangerously (see some of the connections), others are far too hidden away (as Anne has shown). Hopefully you and Peter will get some of this sorted out. 

Neil Brown wrote:

Kevin (and the list),
So you are suggesting a protected schedule() method that simply calls the Alternative.schedule() package-private method? I think that would make sense to go in Guard and, as you say, it should allow new guards to be implemented. Peter and I are currently trying to reshuffle the internal class arrangement so we can look at including that change. I'm not sure that JCSP was ever structured with the intention of being extendible, so it is interesting to see that Anne has a requirement for it. 

Neil.

Kevin Chalmers wrote:

Hi folks,
Just a thought on this one quickly (Neil I'd like your opinion especially). Why not place a schedule method in the AltingChannelInput abstract class, or even Guard, with protected level visibility. This would allow all derived classes of Guard to call schedule, but remove the restriction that it must be in jcsp.lang. This would solve Anne's problem, but still not expose Alternative to the outside world too much, only via Guards. Personally I've never had a call to implement a new Guard, all my new channels extend NetAltingChannelInput, and are therefore automatically Guards without much hassle. However, it does seem a necessary feature by the looks of things.
On another note, I am getting pretty close to having our .NET CSP library ready for a release. Sorry for the delay. After the poor results (solved by Ruth) I was going to scrap it, but after the interest I have been working on it when I can. Really, all I need to do is finish off the documentation. I initially was going to write it all myself, but I am now getting lazy and cutting and altering from JCSP documentation to speed up the process. Any interest let me know. I will post again when I'm ready (hopefully in a week or two). 

Regards

Kevin Chalmers
Research Student
School of Computing
Napier University
Edinburgh

Anne van Rossum wrote:

Hi Kevin,

Thanks for your response. The code from One2OneChannelImpl can not be
copied, because it uses the method .schedule() from the Alternative
class in the .util package that is not visible outside that package.

I want to have different classes of components. Let I use the following
terminology:
      * CodeBlocks: implement CSProcess but send and receive "normal"
        data over their channel inputs and outputs;
      * Interpreters: implement CSProcess and may send and receive
        CodeBlock's over their channel inputs and outputs. Interpreters
        therefore are able to schedule, manipulate CodeBlock's. In this
        way e.g. different scheduling techniques can be tried in
        parallel. Or  interpreters may only understand CodeBlock's in a
certain programming language. They function as virtual machines; 
      * Universal Interpreters: implement (in Java) CSProcess and may
        send and receive Interpreters over their channel inputs and
        outputs. Channel's should cross-language and cross-platform in
        the sense of pipes, CORBA, tcp/ip. Transporting an interpreter
        to another machine corresponds with e.g. downloading a JRE to
        that machine. They are a kind of "universal" virtual machines.

CodeBlock's have certain restrictions on their channel inputs that I
address explicitely.
I will temporarily remove the extension of the AltingChannelInput class. 

That channel endpoints are separate entities is indeed useful. They are
in other Java libraries modelled as InputPipe and OutputPipe (JXTA), as
SourceChannel and SinkChannel (java.nio.channels), as Puttable and
Takable (java.util.concurrent).

Kind regards,

Anne

On Tue, 2007-01-09 at 17:16 +0000, Kevin Chalmers wrote:

Hi Anne,
In Peter Welch's original JCSP library, the channel objects where much more accessible. This does however lead to problems. As an example, consider I receive an object from a channel and then need to check if it is either a ChannelInput or ChannelOutput object. In Peter's library, both of these where the case, and this led to problems in the usage on the JCSP.net library, so Quickstone modified the model somewhat. Therefore the channel ends are each distinct objects from the channel itself.
Now, as for your problem, I suggest simply copying the One2OneChannelImpl code into a new class (One2OneProcChannel) and then use it instead. Ensure the channel extends AltingChannelInput (is therefore guarded and can be used in an Alternative), ChannelOutput and One2OneChannel. This class will therefore be a One2OneChannel as the original, but will allow you to do your modifications. The interface model in JCSP is sufficiently strong to allow this to be fairly routine.
As for the requirement of what you want to do, I am not clear. Normal channels will quite happily carry a CSProcess (everything in Java is an object except primitive data), and the in() and out() methods of One2OneChannelImpl already return this as a result, the channel being both an input and output. If you could clear up the major difference I may be able to help further. 

Regards

Kevin Chalmers
Research Student
Napier University
Edinburgh

Anne van Rossum wrote:

Dear list members,

The JCSP library is nice. However, for my purposes there is too much
package protected. Is this for some reason?
I am creating a special CSProcess, let I call it an Interpreter. The
Interpreter is decoupled from the application functionality (e.g. it
does have several processes in an array). The Interpreter may take care 
of other non-functional aspects:
      * Scheduling: The ParallelInterpreter does have a run() method
        that calls all its processes in a Parallel construct. Other
        interpreters may implement all kind of pool policies. The
        Interpreter can be called a Pool in this scenario;
      * Coupling: Instead of containing an CSProcess array, the
        interpreter may access a pool where processes swim around. It
can take one that performs fast of about which it has positive 
        experiences;
* Process manipulation: An Interpreter may consider its processes 
        and combine them too one new process, before running it:
Transforming channels to (variable) assignments within the same 
        namespace;

To create an Interpreter I want to have ChannelInput's and
ChannelOutput's that carry CSProcess instances. Let I call them
ChannelProcInput's and ChannelProcOutput's. So, the
One2OneProcChannelImpl should implement ChannelProcInput,
ChannelProcOutput and One2OneProcChannel. The methods to overwrite are only in() and out(): public ChannelProcInput in() { return this(); } 
  public ChannelProcOutput out() { return this(); } //and read, write
Regretfully One2OneChannelImpl is package-protected, so I can't extend 
it. Neither can I copy its code, because the method schedule of the
Alternative class is not visible either.

Can the visibility be adapted? Or should I create my adapted jcsp
library? In that case I need at last the source code of the
com.quickstone.jcsp.util library. Thanks in advance!

Kind regards,

Anne

On Tue, 2007-01-02 at 10:38 +0100, Anne van Rossum wrote:

Dear list members,
Currently I am playing with the JCSP library. I wrote this code that has a Writer that writes values on channelA, an Incrementer that increments 
those values and a Reader that reads them and displays them at the
console:

Code:
public static void main(String[] args) {
    ChannelFactory channelFactory = new StandardChannelFactory();
    One2OneChannel channelA = channelFactory.createOne2One();
    One2OneChannel channelB = channelFactory.createOne2One();
       Parallel processPool = new Parallel(
      new CSProcess[] {
          new Writer(channelA.out()),
new Incrementer(channelA.in(), channelB.out()), new Reader(channelB.in()) 
      }
    );

    processPool.run();
  }

Questions:
I have the following questions regarding this example:
* The CSProcesses run parallel, but it is unclear how each process gets 
its processing time. Maybe the Reader gets much more cycles than the
Writer. Who knows?
* The CSProcesses may be placed in any order. The Incrementer can not 
read a value from its input channel when it is not available. How is
this implemented? Is the Incrementer polling channelA? Or send channelA 
an event to the Incrementer?
* The nomenclature of channel.in() and channel.out() is confusing.
Channel.out() should be the endpoint of the channel, not the output of 
the component where a channel starts. If a channel is a first-class
entity, it should be treated like that.
* The Parallel construct is rigid. Why is it not coupled to some kind of "parallel" thread pool (or actually a process pool)? The implementation of above gives all processes (supposedly) the same amount of processing time in parallel. An "alternative" construct is also allowed. And some implementing "priorities". That's it. How can I code other process pools 
with other policies?
* On rewiring the network the One2OneChannel object has to be replaced 
by an Any2OneChannel object or One2AnyChannel object, etc. How can a
process removed easily? There is a Parallel.removeProcess method that will be executed before a call to run(). The Reader process above reads continuously from channelB and never stops. How can I swap the Writer 
for another in that case? Code after processPool.run() will not be
reached.
* How many threads are there actually? Has every channel, or every
"plug" of a channel their own thread? Or only the CSProcess objects?

Background:
What do I have in mind? I like to develop large-grain dataflow model
where the large-grain processes are aggregations of small-grain
processes (and have a better performance). If such a conversion (from 
small to large-grain processes) can be automated, software will
automatically adjust to the amount and type of hardware processors
(multiple CPUs, FPGAs, etc.) For that:
* Different CSProcesses should be implemented;
* Those should be swapped for each other easily;
* Those should be compared w.r.t. performance;
* Aggregations of CSProcesses should be compared with the distinct
CSProcesses w.r.t. performance;
* Channels should be plugged somewhere else easily.
Etc. etc.

Thanks a lot in advance for taking time!

Kind regards,

Anne
This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender. It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University.
This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender. It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University. 








This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender.
It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss
or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University.