Details

    • Type: Sub-task Sub-task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: DRLVM
    • Labels:
      None
    • Patch Info:
      Patch Available

      Description

      This is a splitted out part of H-1789.patch from HARMONY-1789, originally posted by Nikolay Kuznetsov.

      fix-thread-start.patch fixes Thread.start() to remember interrupted status if interruptions occur while it waits for the other thread to start,
      and restore interrupted status before returning.

        Issue Links

          Activity

          Hide
          Alexei Fedotov added a comment -

          Since this bug doesn't contain a test by itself, I believe it can be closed since the test from HARMONY-2366 is fixed by this patch.

          Show
          Alexei Fedotov added a comment - Since this bug doesn't contain a test by itself, I believe it can be closed since the test from HARMONY-2366 is fixed by this patch.
          Hide
          Alexey Petrenko added a comment -

          The patch has been applied.
          Salikh, please verify.

          Show
          Alexey Petrenko added a comment - The patch has been applied. Salikh, please verify.
          Hide
          Salikh Zakirov added a comment -

          Understood and agreed.
          The other relevant reference on why whould we wait for the thread be really started is from isAlive() specification:

          ... A thread is alive if it has been started and has not yet died. ...

          This implies, that thread is required to be alive after method start() returned.
          And since we define "being alive" as "user function run() was called but not yet returned or terminated by exception", this implies that start()
          must wait until the thread status has been changed to be alive, just before calling run() function.

          Concerning the loosing interruption, the issue HARMONY-2366 describes how it affects ThreadTest from luni module of classlib unit tests.

          Show
          Salikh Zakirov added a comment - Understood and agreed. The other relevant reference on why whould we wait for the thread be really started is from isAlive() specification: ... A thread is alive if it has been started and has not yet died. ... This implies, that thread is required to be alive after method start() returned. And since we define "being alive" as "user function run() was called but not yet returned or terminated by exception", this implies that start() must wait until the thread status has been changed to be alive, just before calling run() function. Concerning the loosing interruption, the issue HARMONY-2366 describes how it affects ThreadTest from luni module of classlib unit tests.
          Hide
          Nikolay Kuznetsov added a comment -

          Salikh, here is my answer to your question from 1789:
          > By the way, why we have a waiting loop in Thread.start() at all? Spec does not mandate it. – I think I would file a separate JIRA to remove this loop.

          The spec for Thread.start() method says that:
          "!!!Unable to render embedded object: File (The result is that two threads are running concurrently) not found.!!!!:
          the current thread (which returns from the call to the start method) and the other thread (which executes its run method)."

          It seems to me that this means that after return from the start method both threads should be alive and running, thus synchronization required to wait until child thread run method was called. The right method to implement this in java(synchronization on native side is also possible) is to put lock.wait() method into while loop on isAlive condition, to avoid spurious wake-ups and provide expected behavior in any case.

          Also, interrupting waiting on start methos thread may cause InterruptedException which is not expected from the start method, but just ignoring it is also incorrect, because it may turn into lost interruption. Thus forwarding interrupted status seems to be easiest and correct solution for java style start method synchronization.

          Thank you.
          Nik.

          Show
          Nikolay Kuznetsov added a comment - Salikh, here is my answer to your question from 1789: > By the way, why we have a waiting loop in Thread.start() at all? Spec does not mandate it. – I think I would file a separate JIRA to remove this loop. The spec for Thread.start() method says that: "!!! Unable to render embedded object: File (The result is that two threads are running concurrently) not found. !!!!: the current thread (which returns from the call to the start method) and the other thread (which executes its run method)." It seems to me that this means that after return from the start method both threads should be alive and running, thus synchronization required to wait until child thread run method was called. The right method to implement this in java (synchronization on native side is also possible) is to put lock.wait() method into while loop on isAlive condition, to avoid spurious wake-ups and provide expected behavior in any case. Also, interrupting waiting on start methos thread may cause InterruptedException which is not expected from the start method, but just ignoring it is also incorrect, because it may turn into lost interruption. Thus forwarding interrupted status seems to be easiest and correct solution for java style start method synchronization. Thank you. Nik.

            People

            • Assignee:
              Alexey Petrenko
              Reporter:
              Salikh Zakirov
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development