[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: It was a stressing weekend!
From: Rick van Rein [mailto:vanrein@xxxxxxxxxxxxx]
Sent: donderdag 25 maart 1999 13:33
Subject: Re: It was a stressing weekend!
>> I immediately wrote a
>> Java test program as you suggested to stress the CTJ-alternative
>> in the hope to encounter the race hazard (see the test program below).
>> 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.
>Furthermore, I've already warned you about it a few years ago.
>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
>It's unacceptable to rely on a particular VM's implementation of threads;
>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
>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