> EPICS Mutexes in an interrupt context … crashes
No idea about RTEMS in particular, but you can generally not _take_ a mutex in an interrupt context.
You may be able to _give_ a mutex to wake a thread that’s waiting on that mutex, but details will depend on the OS.
You can use epicsEvent from within an interrupt service routine to signal a thread that it should start doing some work.
If the interrupt context currently uses mutexes, it might be best to rewrite it to use epicsEvent and maybe move work out of the interrupt service routine into a thread that’s woken by the event.
On 2025-03-20, 9:32 AM, "Tech-talk" <tech-talk-bounces at aps.anl.gov> wrote:
the ‘USE_POSIX_THREAD_PRIORITY_SCHEDULING = NO’' is an EPICS thing.
I don't know exactly what this does as I have never used it with RTEMS.
I think that cancels out the whole point of a priority-based system ;-)
All your jobs have a very low priority 253 (in RTEMS) and priority 2 in Posix.
Based on my gut feeling, I would recommend setting back to USE_POSIX_THREAD_PRIORITY_SCHEDULING=YES and then
in rtems_init for POSIX_Init() to set the priority high. You can use the code element I sent to you in the last tech-talk-reply.
Then all the interrupt handlers will also get a high priority and I assume that the crashes will also go away.
Would you like to try that?
> Thank you for the information. There's definitely something fishy going on with the thread priorities somewhere; it seems that everything is being started with the same priority.
> I will also note that we are building RTEMS with "USE_POSIX_THREAD_PRIORITY_SCHEDULING = NO". This appears to be required, as we use EPICS Mutexes in an interrupt context, and if we leave this set to "YES" we see a crashes. Could this
be related to the oddities below?