-
Notifications
You must be signed in to change notification settings - Fork 17
Open
Description
Quite often I experience this algorithm never returning with thread dumps looking like this:
"main" #3 [10220] prio=5 os_prio=0 cpu=31.25ms elapsed=88.63s tid=0x00000112a866f880 nid=10220 waiting on condition [0x0000000c4eaff000]
java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@24/Native Method)
- parking to wait for <0x000000070cc1f4e0> (a java.util.concurrent.Semaphore$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(java.base@24/LockSupport.java:223)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@24/AbstractQueuedSynchronizer.java:789)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(java.base@24/AbstractQueuedSynchronizer.java:1138)
at java.util.concurrent.Semaphore.acquire(java.base@24/Semaphore.java:318)
at kn.uni.voronoitreemap.treemap.VoronoiTreemap.computeLocked(VoronoiTreemap.java:196)
at podbrushkin.MainCli.computeVoronoiTreemapPolygons(MainCli.java:257)
at podbrushkin.MainCli.main(MainCli.java:151)
| lock.acquire(); |
It can happen even for a tree with 20 nodes.
Is it known? Can I do anything further to pinpoint this issue?
All deadlocks I was getting were with 8 threads, I've tried running with 1 thread and didn't encounter a single deadlock yet.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels