With an application of this complexity it seems a lot more likely that
there is a deadlock or other synchronization bug in your own code, rather
than something wrong with the (relatively straightforward) implementation
of thread synchronization in the JDK. If you can come up with a simple
example program which
The fact that you haven't seen this problem under Solaris or WinNT isn't
a good argument for a bug in the Linux JDK; these things may be cropping
up due to race conditions, or else differing (but correct!) implementations
of the threading system.
Matt Welsh
"R.W. Shore" <[EMAIL PROTECTED]> writes:
> I suspect that there's a bad problem with thread
> synchronization. Has anybody else seen similar symptoms??
>
> Platform: Cyrix M-II running RedHat 6.0
> JDK: 1.1.7 from Blackdown
> Green threads, default JIT setting (on?)
> Classes compiled with JDK 1.1.6 on a WinNT platform
> (VisualCafe)
>
> Problem: I've got an application that, among other things,
> maintains an "event log". Since the log entries can go to
> several places, including but not limited to a local file,
> and since I didn't want the logging threads to have to wait,
> I put the logging into a separate thread. The interface
> between the log-maintenance thread and the rest of the app
> is a "bucket" object, which is a limited-size FIFO queue. A
> thread can put a log request into the bucket; the
> log-maintenance thread extracts the request from the bucket,
> processes it, and loops back to get the next request. The
> bucket uses synchronized blocks with wait() and notifyAll()
> calls to coordinate the maintenance thread with the other
> threads. This approach has worked fine on WinNT and Solaris
> 2.7.
>
> The first thing I noticed when running the app on the
> Blackdown JDK was mysterious hangs. To fix this, I first
> inserted some yield() calls outside the synchronized blocks,
> after each bucket put and get. This helped but didn't
> completely solve the problem. I then modified the
> maintenance thread so that it runs at a thread priority of
> 1+whatever the default is -- no more hangs. Hmmm...
>
> Now, the actual environment involves three separate
> platforms. Call 'em A, L, and C, where L is the Linux
> platform. Platform A sends a request to L via CORBA, which
> processes it and sends the result to C. All three platforms
> maintain logs of requests. What I'm seeing now is an
> occasional double logging on L. That is, A logs requests 1,
> 2, and 3; C logs results 1, 2, and 3; but L logs processing
> 1, 2, 2, and 3. Keep in mind that I don't see any such
> behavior on either WinNT or Solaris. Hmmm...
>
> I'm concluding that there's something seriously wrong with
> thread synchronization, at least on this platform. Proper
> synchronization of threads is critical to this application,
> and I'm starting to wonder if there are other processing
> anomalies on the Linux box that I'm simply not seeing.
> Although I haven't made extensive tests, the problem doesn't
> appear to be JIT related -- at least, the original app hangs
> persisted when I turned the JIT off (java.compiler=NONE).
>
> My questions include:
>
> o Has anybody seen similar synchronization behavior?
>
> o Anybody want to venture an opinion on the likelihood of a
> chip-related problem vs a JDK-related one?
>
>
> ----------------------------------------------------------------------
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
