Re: Real-time Java?

["P.H.Welch" <P.H.Welch@xxxxxxxxx>]

Rick,

> *) there are loads of other issues, but I was struck by the inter-thread
> channels. These clearly take their origin from the
> PipedInputStream/PipedOutpuStream i/o stuff. What they are trying to
> achieve is occam (/CSP) channels. What they actually have is some
> muddled hybrid in which either end (but not both) is non-blocking, the
> opposite end being blocking. Yuk! A total mess: Entia non sunt
> multiplicanda praeter necessitatatem I say!

You're so right.  But I don't think they're *trying* to invent channels.
They're kind of forced into it for another reason - in this case, to be
able to make real-time guarantees when an rt-process has to communicate
with an "ordinary" one.  Here's a comment I mailed someone else last August:

> It sounds like the Sun people are slowly inventing bits of CSP in dribs
> and drabs.  For instance, that rt-java spec from Sun et al ... they've
> invented a One2AnyChannel for communicating between a real-time process
> and an ordinary one.  They daren't use the sync/wait/notify business
> in case a non-real-time process (sorry, thread) gets jumped on by the
> garbage collector whilst holding a lock the real-time thread wants.  So,
> they have this One2AnyChannel programmed as an overwriting buffer.

Actually, that should have been "overflowing" - not "overwriting".  When
the buffer is full, it throws away new stuff (not old stuff).

But why invent the asymetric "One2Any..." variety?  Multiple ordinary
processes can compete safely to read from the channel - but it's only
safe for one rt-process to write to it.  To allow many rt-writers, we
have to get them to lock it first.

And, as you say, there's the asymmetry of a blocking-when-empty read and
an overflowing-when-full write.

I went on (sorry):

> These things are kind of specialised and easy (and efficient) to generate
> from CSP primitives (it actually *is* a JCSP primitive!).  But by going
> for what they need to get out of a hole they're in, they miss the big
> picture and the *nice* story!  CSP sets out a (much more) complete set
> of primitives, it's been around for ages and is very mature ... but they
> won't look at it.

There's a new package coming out for Java 1.4 - java.nio ("new I/O" ?).
I'm told that this includes a Selector/Selectable framework (shades of
Observer/Observable?) that can wait on multiple events.  Sounds like
they are groping towards an ALT ;-)

Again, if so, they are missing the big clean efficient and simple picture ...

Business as usual, I guess,

Cheers,

Peter.