Date: Fri, 04 Jun 2004 02:43:21 +0200 From: Ronald Klop <ronald-freebsd7@klop.yi.org> To: Nate Williams <nate@yogotech.com> Cc: java@freebsd.org Subject: Re: possible threading problem Message-ID: <opr81oajwwm97yfk@outgoing.local> In-Reply-To: <16575.44523.933426.867439@emerger.yogotech.com> References: <20040601154601.0869f5b4@psych.iad.vt.edu> <40BD7C06.5050205@noc.ntua.gr> <20040602095245.48cb3c44@psych.iad.vt.edu> <opr8zfpxqaydasmi@outgoing.local> <20040603120810.096a1975@psych.iad.vt.edu> <opr81c9s0xm97yfk@outgoing.local> <16575.44523.933426.867439@emerger.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 Jun 2004 17:02:03 -0600, Nate Williams <nate@yogotech.com> wrote: > [ Note, I have not analyzed the code in question, but from the sounds of > things, the behavior the posted is probably 'acceptable' on FreeBSD. ] > >> 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. > > This is right on the money. Different threading models will behave very > differently. Prior to JDK1.4 on Solaris (the reference platform), you > could get *very* different results by choosing to use green threads > vs. native threads. And, things got even more different when you > started using a JIT, which could cause behavior that appeared to be > non-deterministic. > > In every good Java book, the use of 'interrupt', 'stop', and any other > method stats that the results you get *WILL* be different. Just because > one platform behaves a particular way doesn't necessarily mean it's > correct (or that any platform is correct). > >> 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. > > In the JVM, or in the code? (I'm guessing the latter, but I want to > make sure of your intent). Yes, I mean the code. And with 'looks like' I mean that it isn't, but it makes you think it is a problem in the synchronization. I'll explain: If somebody thinks that interrupt() and the InterruptedIOException are occuring at the same moment, but the stacktrace of the exception shows the program is executing in a part which can never happen at the same moment as the interrupt() call (because of synchronized blocks) I can understand that somebody gets the idea that synchronization isn't working well. Greetings, Ronald. -- Ronald Klop, Amsterdam, The Netherlands
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?opr81oajwwm97yfk>