Thanks. I agree that there's a non-zero probability of a bug
in my code, but being a lazy programmer I thought I'd ask
the question first.
Bob
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of Matt Welsh
Sent: Thursday, August 05, 1999 15:55
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Bad sync problem??
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]
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
