Java Threads mailing list archive

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.
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 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.

> 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.

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.


Greetings,

Rick van Rein,
	Spiritus flexibilis in corpore flexibile
--
Universiteit Twente * INF-3027 * Postbus 217 * 7500 AE Enschede * 053-4894291