FW: It was a stressing weekend!

["Gerald Hilderink" <g.h.hilderink@xxxxxxxxxxxxx>]

-----Original Message-----
From: Rick van Rein [mailto:vanrein@xxxxxxxxxxxxx]
Sent: donderdag 25 maart 1999 13:33
To: java-threads@xxxxxxxxx
Subject: Re: It was a stressing weekend!


>Gerald,
>
>> I immediately wrote a
>> Java test program as you suggested to stress the CTJ-alternative
construct
>> in the hope to encounter the race hazard (see the test program below).
The
>> CTJ-alternative construct works fine and it seems that it does not suffer
>> from the mentioned race hazard.
>
>Err... you mean, you didn't encounter it.

Yes, I didn't encounter it.

>You cannot proof by testing that it doesn't work, but one counter-example
>(like Peter's) suffices to show your work is wrong. Karl Popper.

I Agree.

>Furthermore, I've already warned you about it a few years ago.

You did?

>
>Maybe you rely on implementation details of your specific VM which make it
>accidentally go well on your machine, or maybe you've just been lucky so
far.
>
>It's unacceptable to rely on a particular VM's implementation of threads;
the
>behaviour may differ accross platforms, e.g. think of preemptive scheduling
>versus cooperative scheduling, or think of queue signalling order. Those
>things are (deliberately) not specified in Java, but a particular VM makes
>a choice, of course.

Does this mean that you wonn't use Java threads anymore?

I agree! That's why we build our own scheduler that tightly specifies
similar behaviour across platforms.

>> Threads and synchronised methods are for special skilled programmers
>> and they are a significant barrier for the rest of designers and
>> programmers.
>
>Once again, I disagree.  The synchronisation constructs function well for
>building conceptual models of systems.

I disagree, because the Alternative bug is a result of this.
By experience, I have learned otherwise.

>However, if you want to use Java as an implementation platform, you may
>need to tweak more --- that's just because your desires from the platform
>are different from what Java was intended for --- it's simply *not*
>designed as a fully controllable, entirely deterministic language.

Is this acceptable? If Java is *not* designed as a fully controllable and
entirely deterministic language then is there a futhure for EmbeddedJava and
Real-Time java?

Cheers,
Gerald.