harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm] stress.Mix / MegaSpawn threading bug
Date Tue, 16 Jan 2007 18:04:33 GMT
There is some history in this that I read through in Harmony issues 1789,
2219, and now 2963. There may be more.

Possibly the interpretation that the child thread is in run state for
isAlive() to be true is an overinterpretation. The spec seems to intend this
to be implemantation dependent, I could not find any specific reference to
this. The wait/notify/interrupt status forwarding in the implementation seem
to be all based on this assumption.




On 1/12/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
>
> Alexey Varlamov wrote:
> > 2007/1/12, Salikh Zakirov <Salikh.Zakirov@intel.com>:
> >>
> >> > 2007/1/11, Gregory Shimansky <gshimansky@gmail.com>:
> >> >> Another reason for hanging threads is that they wait in
> >> Thread.start().
> >> >> When a new thread is started, it has to notify a lock object, in
> order
> >> >> to signal the parent thread that it has been created. This
> >> notification
> >> >> is sent from java code of the Thread before user code is executed.
> >>
> >> Alexey Varlamov replied:
> >> > IMO the problem is in this design rather than its impl. The
> >> > specification for j.l.Thread.start() does not require that execution
> >> > of run() begins strictly before the start() returned.
> >>
> >> This requirement is implicated by specification of Thread.isAlive():
> >>
> >>    Tests if this thread is alive. A thread is alive
> >>    if it has been started and has not yet died.
> >>
> > I see no problem here: isAlive() must return true after the start()
> > returned, so the thread state is consistent, and that's all.
>
> I've made an experiment with the patch below. I've removed wait/notify
> mechanism and set isAlive in the start method right after
> VMThreadManager.start is called. So isAlive is set twice, on the stack
> of parent thread, and on the stack of created thread before calling
> java. This seem to work just fine, all tests have passed, eclipse works
> too.
>
> I wonder why all this wait/notify stuff was written at all. I think we
> can get rid of it.
>
>
> Index: vm/vmcore/src/kernel_classes/javasrc/java/lang/Thread.java
> ===================================================================
> --- vm/vmcore/src/kernel_classes/javasrc/java/lang/Thread.java
> (revision 495565)
> +++ vm/vmcore/src/kernel_classes/javasrc/java/lang/Thread.java  (working
> copy)
> @@ -663,7 +663,7 @@
>          synchronized (lock) {
>              this.isAlive = true;
>              this.started = true;
> -            lock.notifyAll();
> +//             lock.notifyAll();
>          }
>
>          run();
> @@ -739,19 +739,21 @@
>              if (VMThreadManager.start(this, stackSize, daemon,
> priority) != 0)
> {
>                  throw new OutOfMemoryError("Failed to create new
> thread");
>              }
> -
> -            boolean interrupted = false;
> -            while(!this.started) {
> -                try {
> -                    lock.wait();
> -                } catch (InterruptedException e) {
> -                    interrupted = true;
> -                }
> -            }
>
> -            if (interrupted) {
> -                Thread.currentThread().interrupt();
> -            }
> +            this.started = true;
> +            this.isAlive = true;
> +//             boolean interrupted = false;
> +//             while(!this.started) {
> +//                 try {
> +//                     lock.wait();
> +//                 } catch (InterruptedException e) {
> +//                     interrupted = true;
> +//                 }
> +//             }
> +
> +//             if (interrupted) {
> +//                 Thread.currentThread().interrupt();
> +//             }
>          }
>      }
>
> --
> Gregory
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message