Closed markccchiang closed 1 year ago
Package | Line Rate | Health |
---|---|---|
src.Cache | 68% | ➖ |
src.DataStream | 52% | ➖ |
src.FileList | 67% | ➖ |
src.Frame | 50% | ➖ |
src.HttpServer | 42% | ➖ |
src.ImageData | 28% | ❌ |
src.ImageFitter | 83% | ✔ |
src.ImageGenerators | 43% | ➖ |
src.ImageStats | 76% | ✔ |
src.Logger | 38% | ➖ |
src.Main | 52% | ➖ |
src.Region | 18% | ❌ |
src.Session | 29% | ❌ |
src.Table | 52% | ➖ |
src.ThreadingManager | 87% | ✔ |
src.Timer | 85% | ✔ |
src.Util | 48% | ➖ |
Summary | 38% (7091 / 18732) | ❌ |
Description
What is implemented or fixed? Mention the linked issue(s), if any. Closes #1328.
How does this PR solve the issue? Give a brief summary. This problem is due to the deadlock of two mutexes,
_active_task_mutex
and_region_mutex
, in the RegionHandler methods. When a region spectral profile process starts,_active_task_mutex
is taken in the method GetRegionSpectralData. Then the_region_mutex
will be frequently taken inside this method RegionFileIdsValid to check whether the region object exists or it is disconnected. If we delete the region during this process, theRemoveRegion
method is called, and the_region_mutex
is taken here inside this function. Then it waits to take_active_task_mutex
in the WaitForTaskCancellation. Two methodsGetRegionSpectralData
andRemoveRegion
are waiting for the same mutexes_active_task_mutex
and_region_mutex
. The solution is to remove the_region_mutex
from theRegionSet
method. Since it only reads the status of region objects and does not modify the_regions
map. Removing this mutex allows the RegionFileIdsValid to get rid of_region_mutex
(since it can be taken byRemoveRegion
at the same time), so it can pass the disconnected signal and stop the region spectral profile process. Finally, the region object can be deleted.Are there any companion PRs (frontend, protobuf)? No.
Is there anything else that testers should know (e.g. exactly how to reproduce the issue)? The hanging problem of region spectral profiles should be solved.
Checklist