On Thu, 3 Jun 2004 12:08:10 -0400, Daniel Fisher

> On Wed, 02 Jun 2004 21:42:59 +0200
> Ronald Klop wrote:
>> On Wed, 2 Jun 2004 09:52:45 -0400, Daniel Fisher
>> wrote:
>> > On Wed, 02 Jun 2004 10:04:38 +0300
>> > Panagiotis Astithas wrote:
>> >
>> >> Daniel Fisher wrote:
>> >> > I'm experiencing a weird threading problem with jdk-1.4.2p6_3 that

>> I
>> >> don't
>> >> > see on Linux.
>> >> > It looks like the BSD JDK is not honoring sychronize statements.
>> >> > Has anyone seen this before?
>> >> > If not, who should I send sample code to?
>> >>
>> >> Um, the list?
>> >> --
>> >> Panagiotis Astithas
>> >
>> > Alrighty then....
>> > attached is a tarball with the sample classes in it.
>> > Untar and cd into the directory.
>> > Execute: java -jar prop.jar
>> > These classes monitor the main.properties file and echo the changes to
>> > stdout.
>> > Edit main.properties while the java job is running.
>> > FreeBSD JVM throws an InterruptedIOException, Linux JVM does not

>> throw an
>> > exception.

>> Add debugging like, so you can make sure synchronized is (not) working.
>> synchronized (a) {
>> System.out.println("In a 1");
>> ...
>> System.out.println("Out a 1");
>> }
>> If I recompile your program I get other results after modifying the
>> properties file.
>> java.lang.NoClassDefFoundError: prop/PropEvent
>> at prop.PropSingleton.removeProperties(PropSingleton. java:74)
>> at prop.PropMonitor.run(PropMonitor.java:71)
>> at java.lang.Thread.run(Thread.java:534)
>> PropMonitor interrupts itself. Why? it's useless.
>> By the way if you don't do this your program works.
>> Offtopic:
>> In PropMonitor you catch Exception. So you will mis all other possible
>> error messages from java.
>> If this is not just a test class I would rewrite it.
>> Why this:
>> try {
>> throw Exception();
>> } catch (Exception) {
>> break;
>> }
>> You can also just do break in stead of the exception.
>> And you can remove all the interrupt/interrupted calls. Only keep the
>> boolean run.
>> And even nicer than the break is setting run = false to end the while.
>> But only removing the stopMonitor call from PropMonitor.run() will also
>> make it work. :-)
>> Ronald.

> I think you've missed the point.
> The question is, why does the BSD JVM behave differently and does it need
> fixing?

But you mention a synchronization problem. And I gave an hint about how
to modify your program to show the synchronizations and if the FreeBSD
Java ignores it.
You are using threads. Threads are non-deterministic, so different os'es
can show different things. In your program you ignore exceptions by
catching Exception and not printing/logging it. So maybe you just don't
see the exception on Linux.

The point I tried to make is, that it is not clear from your example
that java is doing something wrong. Only that it is doing something
different than another JVM on another OS. Running the program on Windows
might give even other results.

BTW: You interrupt your own thread. The javadoc's say that if the thread
is not blocked it will set the interrupted flag. I think that the next
time a blocking syscall is done the InterruptedIOException is thrown,
because the interrupted flag is set. So the InterruptedIOException can be
thrown at a very different moment than that the thread.interrupt() call
was done. I'm not sure about this, because I don't know enough about the
internals of java, but it can be the reason, that it looks like a
synchronization problem. Printing more debug info, can show you this. But
beware that the printing of the debug info can interfere with the rest of
the program.

I hope this helps you in debugging this,


Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
freebsd-java@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-java-unsubscribe@freebsd.org"