On 1/2/07, Oleg Oleinik <[EMAIL PROTECTED]> wrote:
> while (current != worker && k < 100000) {k++;}
> The burning question is why was the "k < 100000" test added?
Look like "k<100000" is added to avoid test hanging, looks like it
should be removed. Let me think more.
I also suspect the "k<1000000" was added to avoid test hanging. If the
test does, in fact, hang when "k<1000000" is removed, we have a whole new
set of problems to deal with. It could be the case that this test
"reliably" passes with a known race condition. In other words, this test
may indicate bugs in the test as well as the JVM. My experience is that
these kinds of issues can be very difficult and time consuming as they
involve the hardware's memory consistency model as well as the software
running on top.
On 1/1/07, Weldon Washburn <[EMAIL PROTECTED]> wrote:
> On 12/28/06, Oleg Oleinik <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > Reliability test suite is contributed on behalf of Intel:
> >
> > http://issues.apache.org/jira/browse/HARMONY-2918
> >
> > The tests are intended to verify ability of the runtime to run
> > successfully for long time. The suite contains 72 tests (covering
> > mainly kernel, nio, text, io, net, zip classes functionality, plus a
> > couple of tests for VM) and ant scripts to build and run tests.
> >
> > The tests are intented to be integrated into buildtest/. Please review
> > and comment.
>
>
> This is great. These are much needed tests.
>
> I have started looking at the tests and have questions about
> kernel/thread/VolatileVariableTest/DekkerTest.java.
>
> regionIn() corresponds to the part of the Dekker algorithm that acquires
the
> critical section. regionIn() contains code that, as far as I can tell,
is
> not part of the Dekker algorithm. regionIn() spins for 100000 loops
then
> assumes/pretends the critical section has been acquired (??). The line
of
> code I refer to is:
>
> while (current != worker && k < 100000) {k++;}
>
> From reading the Dekker algo reference, it seems this line of code
probably
> should be:
>
> while (current != worker) { }
>
> The burning question is why was the "k < 100000" test added?
>
> At the top of DekkerTest.java it says, "Goal: check that VM supports
> volatile variables". My guess is that the JIT must put memory fence(s)
> around volatile variable reads and writes. My guess is that Dekker is
> probably one of the few ways to actually test for proper implementation.
> But I really worry that the JIT could accidentally miss emitting the
memory
> fence(s). And DekkerTest.java would pass anyway. Does it make sense to
> create "DekkerTest2.java" that is identical to DekkerTest.java where all
the
> "volatile" kepwords are omitted? The intention is to create a test that
> will hard fail if the memory fences are not emitted.
>
>
> Best regards, Oleg
> >
>
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
