This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: debugging threads vs processes


My experience with JDK/JNI code at least is that the Java virtual machine
either crashes or all Java threads are hopelessly hung on Linux when you attach
GDB. This Linux bug doesn't only affect Posix semaphores. Ultimately, the
Java monitors invoke Posix monitors and conditions which also wakeup when
you attach the debugger. Having all threads wakeup from blocked monitors
when you attach GDB violates the basic invariant that only one thread can
be within a synchronized section at any given time.

On Friday, July 13, 2001, at 08:51 AM, Cedric Berger wrote:

jpolsonaz@mac.com wrote:

> Has anybody tried using IBM's new Linux threading library with GCJ?
>
> My personal experience with the currently released LinuxThreads is that
> multi-threaded applications are almost undebuggable. LinuxThreads
> currently has a bug that causes all threads to wakeup from semaphores
> the first time you connect a debugger to the process. This, of course, immediately
> crashes most multi-threaded applications since they don't expect to wake
> up until the semaphore actually gets signaled.


The "wakeup from semaphore" should not be too much of a problem in Java,
because properly written Java never blindly trust "semaphores", but use code
be written this way:


synchronized myFunction() {
    while(condition not met)
        object.wait();    // this "semaphore" can get glitches, it doesn't matter.
}


Now, of course, if the "mutex" which is used to implements the "synchronized"
keyword itself suffers the same problem, this would be a disaster....


Anyay, I unfortunately agree with your comments.
Cedric



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]