spaces-X commented on issue #11319: URL: https://github.com/apache/doris/issues/11319#issuecomment-1200708441
> The JDK8's parallelStream has a global thread pool, we can call this `thread resource`, all caller could share this thread pool. `TabletInvertedIndex` has a lock, we call this `lock resource`. If we add a lock out of thread pool, then dead lock could happen between `thread resource` and `lock resource` For example, > > ``` > step 1 Thread 1 get TabletInvertedIndex's read lock. > step 2 Other threads calls parallelStream and the thread pool is full. > step 3 Thread 1 try to submit task to thread pool, but the it is blocked because the thread pool is full. > step 4 Threads in thread pool wants to get TabletInvertedIndex's read lock or write lock, but the lock is held by Thread 1. > Finally, deal lock between thread resource and lock resource happens. > ``` > > And there is still a key question is that why readlock could block read lock. We can refer this https://zhuanlan.zhihu.com/p/34672421. In short, even in unfair policy, write locks are not always preempted by read locks From step 1 to step 3, I think we should follow the principle of acquiring locks when exactly needed in concurrent programming, which will be helpful to avoid many hard-to-recognize deadlock scenarios. -- 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. To unsubscribe, e-mail: commits-unsubscr...@doris.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@doris.apache.org For additional commands, e-mail: commits-h...@doris.apache.org
