java - ReentrantLock -> lockInterruptibly() won't check interrupt state sometimes? -
recently i've been refactoring project "reentrantlock" simplify logic.
general idea is:
1. "main" runnable thread running on own
2. if in order, main thread wait on condition "nextstep"
3. when wrong happened, method "oncancel()" invoked by/in thread, forcing main thread throw interruptionexcpetion, shutdown occur
after tests, turned out own method:
dointerrupt();
never worked expected: forcing main thread enter "interruptedexception" clause , quit loop.
update-2:
i've added "is-interrupted" debug message output log lines, if turns out interrupt state "mysteriously" cleared one...
update:
lock , condition methods:
lock.lockinterruptibly(); condition.await();
seemed not checking interrupt state sometimes? .... javadoc reads: ...... if current thread: has interrupted status set on entry method; or interrupted while acquiring lock, interruptedexception thrown , current thread's interrupted status cleared. ......
log see like:
[action] waiting completion...: 1 [is-interrupted:false] >> debug ---> begin next loop [is-interrupted:false] [action] reset next iteration: 2 [is-interrupted:false] [action] cancelling... [is-interrupted:false] >> debug ---> interrupt [is-interrupted:false] >> debug ---> check. [is-interrupted:true] [action] waiting completion...: 2 [is-interrupted:false] >> debug ---> begin next loop [is-interrupted:false] [action] reset next iteration: 3 [is-interrupted:false] [action] waiting completion...: 3 [is-interrupted:false] >> debug ---> begin next loop [is-interrupted:false] [action] reset next iteration: 4 [is-interrupted:false] [action] waiting completion...: 4 >> debug ---> begin next loop [action] reset next iteration: 5 [action] waiting completion...: 5 >> debug ---> begin next loop [action] reset next iteration: 6 ...... , on until == max [info] main process has reached finish state.
means interrupt signal lost or not processed somehow... there better approach? or fix of code logic @ least?
multi-thread experts???
here's code:
public class sbcstaskengine extends genericengine<sbcstask> implements xlistener { private final reentrantlock lock = new reentrantlock(); private final condition nextstep = lock.newcondition(); private volatile thread main = null; // else ... // it's runnable "main" @override protected void run() { try { main = thread.currentthread(); // setting up... x between 1 ~ 10000 (int = 1; <= max; i++) { lock.lockinterruptibly(); // work ... log("[action] waiting completion...: " + i); // long wait (could fast if task went south) nextstep.await(); if (max == i) { isnormalcompletion = true; } else { log("[action] reset next iteration:" + (i+1)); // reset work... } lock.unlock(); } // end of [for] loop } catch (interruptedexception e) { log("[event] process stopped singal."); } { try { lock.unlock(); } catch (throwable ignored) {} } log("[info] main process has reached finish state."); } private void dointerrupt() { log(">> debug ---> interrupt"); if (main != null) main.interrupt(); log(">> debug ---> check."); } /** * implement: xlistener(series) * instruct main process enter cancel sequence * * known-issue: duplicate call? sync on method? wait risk evaluation */ @override public void oncancel() { log("[action] cancelling..."); dointerrupt(); } /** * implement: xlistener(series) * proceed main thread next loop * * known-issue: signal might occur before "memebers" await on condition (happen-before?), take chance now... */ @override private void donotifynextstep() { try { lock.lockinterruptibly(); log(">> debug ---> begin next loop"); nextstep.signalall(); } catch (interruptedexception e) { dointerrupt(); } { try { lock.unlock(); } catch (throwable ignored) {} } } } // end of [sbcstaskengine] class
more info: java version used:
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)
after careful examine every single method used in "process()", turned out there's method "swallowed" interruptionexception accident...
throw out exception, entire code/class works expected now~~~
huge "@hendalst" commented in post make me revise possible interruption leakage... said: "the code above works", root causing method inside comment area "//some work..." didn't post here...
, "@orionll" suggestion coding principles
Comments
Post a Comment