Yes, Andrew is absolutely right. I unfortunately got the two things mutex vs. event mixed up in the rush. Sorry for that. Viele Grüße Heinz
> On 28. Sep 2021, at 17:11, Johnson, Andrew N. <a...@anl.gov> wrote: > > On Sep 28, 2021, at 5:02 AM, Sebastian Huber > <sebastian.hu...@embedded-brains.de> wrote: >> >> On 28/09/2021 11:46, Heinz Junkes wrote: >>> Unfortunately we found out that EPICS uses the mutex handling also in the >>> interrupt context >>> and this leads to core-dumps in RTEMS :-( >> >> Yes, using any kind of mutexes in interrupt context is undefined behaviour. >> Mutexes may only be used from threads. > > Heinz' reply about our osdMutex may be irrelevant. I suspect the issue is > what if any changes we’d need to make to our implementation of the epicsEvent > found here > https://github.com/epics-base/epics-base/blob/7.0/modules/libcom/src/osi/os/RTEMS-score/osdEvent.c > for a modified version of this to work on an RTEMS-5 or later SMP system. It > creates a semaphore as follows: > >> sc = rtems_semaphore_create (rtems_build_name ('B', c3, c2, c1), >> initialState, >> RTEMS_FIFO | RTEMS_SIMPLE_BINARY_SEMAPHORE | >> RTEMS_NO_INHERIT_PRIORITY | RTEMS_NO_PRIORITY_CEILING | RTEMS_LOCAL, >> 0, >> &sid); > > We will want to use the same code on both SMP and UP systems and from earlier > posts it sounds like they would need different flags. Does RTEMS define a > macro that tells us which we’re compiling for, or will we have to add our own? > >> Which RTEMS semaphore classes do you use in EPICS and in particular which >> classes do you use in interrupt context? > > An epicsEvent must be able to be triggered from interrupt context, and in the > above implementation epicsEventTrigger() calls rtems_semaphore_release(). > That’s the only routine we need AFAIK. > > - Andrew > > -- > Complexity comes for free, simplicity you have to work for. > _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
