Databases
StackOverflow2013
Postsdbo
POReentrantLock -> lockInterruptibly() won't check interrupt state sometimes?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POReentrantLock -> lockInterruptibly() won't check interrupt state sometimes?
    primarykey
    data
    text
    <p>Recently i've been refactoring my project with "ReentrantLock" to simplify the logic.<br> <br> The general idea is:</p> <p> 1. the "main" runnable thread is running on its own<br> 2. if everything is in order, the main thread will wait on a condition "nextStep"<br> 3. when something wrong happened, the method "onCancel()" will be invoked by/in another thread, forcing main thread to throw an InterruptionExcpetion, so the shutdown will occur<br> </p> <p>After some tests, it turned out my own method:</p> <pre><code>doInterrupt(); </code></pre> <p>never worked as expected: forcing main thread enter "InterruptedException" clause and quit the loop.</p> <p> <b>UPDATE-2:</b><br> i've added a "is-interrupted" debug message to all the output log lines, if turns out the interrupt state is "mysteriously" cleared by some one... <br><br> <b>UPDATE:</b><br> The lock and condition methods: <pre><code> lock.lockInterruptibly(); condition.await(); </code></pre> seemed not checking interrupt state SOMETIMES? .... The javadoc reads: <pre> ...... If the current thread: has its interrupted status set on entry to this method; or is interrupted while acquiring the lock, then InterruptedException is thrown and the current thread's interrupted status is cleared. ...... </pre> <br> from the log it could see something like: <pre><code> [action] waiting for completion...: 1 [is-interrupted:false] >> DEBUG ---> will begin next loop [is-interrupted:false] [action] reset for next iteration: 2 [is-interrupted:false] [action] cancelling... [is-interrupted:false] >> DEBUG ---> will interrupt [is-interrupted:false] >> DEBUG ---> check. [is-interrupted:true] [action] waiting for completion...: 2 [is-interrupted:false] >> DEBUG ---> will begin next loop [is-interrupted:false] [action] reset for next iteration: 3 [is-interrupted:false] [action] waiting for completion...: 3 [is-interrupted:false] >> DEBUG ---> will begin next loop [is-interrupted:false] [action] reset for next iteration: 4 [is-interrupted:false] [action] waiting for completion...: 4 >> DEBUG ---> will begin next loop [action] reset for next iteration: 5 [action] waiting for completion...: 5 >> DEBUG ---> will begin next loop [action] reset for next iteration: 6 ...... and so on until i == max [info] main process has reached a finish state. </code></pre> which basically means the interrupt signal is lost or not processed somehow... </p> <p> <b> Is there some better approach? or a fix of my code logic at least?<br> <br> any multi-thread experts??? </b> </p> <p>Here's My Code:</p> <pre><code>public class SBCSTaskEngine extends GenericEngine&lt;SBCSTask&gt; implements XListener { private final ReentrantLock lock = new ReentrantLock(); private final Condition nextStep = lock.newCondition(); private volatile Thread main = null; // something else ... // it's a runnable "MAIN" @Override protected void run() { try { main = Thread.currentThread(); // some setting up... x is between 1 ~ 10000 for (int i = 1; i &lt;= max; i++) { lock.lockInterruptibly(); // some work ... log("[action] waiting for completion...: " + i); // a very long wait (could be REALLY fast if task went south) nextStep.await(); if (max == i) { isNormalCompletion = true; } else { log("[action] reset for next iteration:" + (i+1)); // some reset work... } lock.unlock(); } // end of [for] loop } catch (InterruptedException e) { log("[event] process stopped by singal."); } finally { try { lock.unlock(); } catch (Throwable ignored) {} } log("[info] main process has reached a finish state."); } private void doInterrupt() { log("&gt;&gt; DEBUG ---&gt; will interrupt"); if (main != null) main.interrupt(); log("&gt;&gt; DEBUG ---&gt; check."); } /** * implement: XListener(series) * instruct main process to enter cancel sequence * * known-issue: duplicate call? sync on method? wait for risk evaluation */ @Override public void onCancel() { log("[action] cancelling..."); doInterrupt(); } /** * implement: XListener(series) * proceed the main thread to next loop * * known-issue: signal might occur before all "memebers" could await on the condition (happen-before?), just take the chance for now... */ @Override private void doNotifyNextStep() { try { lock.lockInterruptibly(); log("&gt;&gt; DEBUG ---&gt; will begin next loop"); nextStep.signalAll(); } catch (InterruptedException e) { doInterrupt(); } finally { try { lock.unlock(); } catch (Throwable ignored) {} } } } // end of [SBCSTaskEngine] class </code></pre> <p><br> More Info: Java version I used:</p> <blockquote> <pre><code>java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) </code></pre> </blockquote>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USLeemax
    1. USLeemax
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POReentrantLock -> lockInterruptibly() won't check interrupt state sometimes?
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POReentrantLock -> lockInterruptibly() won't check interrupt state sometimes?
      1. USsjlee
      1. VTFavorite
    3. VO
      singulars
      1. POReentrantLock -> lockInterruptibly() won't check interrupt state sometimes?
      1. This table or related slice is empty.
      1. VTClose
    1. COTry to make all the fields final (lock, nextStep and main)
      singulars
      1. POReentrantLock -> lockInterruptibly() won't check interrupt state sometimes?
      1. USZhekaKozlov
    2. COorionll << why ? can you explain ? shouldn't the Sync implementation inside the ReentrantLock does the work?
      singulars
      1. POReentrantLock -> lockInterruptibly() won't check interrupt state sometimes?
      1. USLeemax
    3. COIt seems that there are some design issues in your code. Please, read the following guidelines: https://www.securecoding.cert.org/confluence/display/java/VNA00-J.+Ensure+visibility+when+accessing+shared+primitive+variables https://www.securecoding.cert.org/confluence/display/java/THI03-J.+Always+invoke+wait()+and+await()+methods+inside+a+loop
      singulars
      1. POReentrantLock -> lockInterruptibly() won't check interrupt state sometimes?
      1. USZhekaKozlov
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload