MantisBT - JANA |
View Issue Details |
|
ID | Project | Category | View Status | Date Submitted | Last Update |
0000298 | JANA | Feature Request | public | 2012-12-20 08:27 | 2013-01-22 15:39 |
|
Reporter | davidl | |
Assigned To | davidl | |
Priority | normal | Severity | minor | Reproducibility | N/A |
Status | resolved | Resolution | fixed | |
Platform | | OS | | OS Version | |
|
Summary | 0000298: Need list of mutexes to unlock in thread_HUP_sighandler |
Description | If a thread happens to hold a mutex lock when it is killed by an HUP signal then the replacement thread (or any other) will gridlock. (The HUP signal is sent by the main thread when the processing thread exceeds the timeout specified for processing a single event.) This occurred during the GlueX data challenge occasionally, apparently due to events taking a long time to write to disk (network issues?).
The fix is to have JANA maintain a list of mutex pointers (registered by user code) that can be unlocked in the thread_HUP_sighandler routine. The mutexes will need to be of type ERRORCHECKING so they behave correctly if the mutex is not locked by us when we attempt to unlock it. Ideally, this will be checked at the time the mutex is registered so an error can be issued. |
Steps To Reproduce | |
Additional Information | The original problem manifest in mcsmear because it implemented its own mutex for serializing writing to the output file. This problem will exist for all output systems since they will all need to implement a similar mutex. It may be worth considering re-implementing the JEventSink base class to standardize this (??) |
Tags | No tags attached. |
Relationships | |
Attached Files | |
|
Issue History |
Date Modified | Username | Field | Change |
2012-12-20 08:27 | davidl | New Issue | |
2013-01-22 15:39 | davidl | Note Added: 0000453 | |
2013-01-22 15:39 | davidl | Status | new => resolved |
2013-01-22 15:39 | davidl | Resolution | open => fixed |
2013-01-22 15:39 | davidl | Assigned To | => davidl |