xiaoHoly commented on pull request #14076: URL: https://github.com/apache/flink/pull/14076#issuecomment-731058522
@tillrohrmann ,Maybe I found the reason for the instability. It depends on when the thread A calling the await() method acquires the lock of the lock object in the jvm lock pool. According to the lock.wait() code in the await() method, we will know that it will cause the current thread A to enter the blocking state. At this point, trigger() will perform its work in the thread B to which it belongs. Suppose that when thread B executes to lock.notifyAll(), thread A will be awakened, but the lock of the lock object is not allocated in time and is still blocked. As long as the interrupt flag of thread A is true, InterruptedException will be thrown. So I thought of two solutions. The first point: Thread B changes the interrupt flag of thread A to false before executing lock.notifyAll(). This method can ensure that the A thread will not throw InterruptedException after being awakened, but how to restore the thread interruption flag for different threads still needs to be considered. T he second point: Use catch code to catch the exception in the A thread, it will automatically restore the thread interruption flag, and make the compilation pass. But the second method cannot solve the problem of exception throwing. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
