> On 30/03/2022 15:19, gabriel.moy...@dlr.de wrote:
> >>> Ok, it seems the pps_event() could be called by interrupt service
> >>> routines. In this case, you cannot use a mutex and condition variables.
> >>> You have to use a thread queue directly. Use the thread queue ISR
> >>> lock for mutual exclusion. Use _Thread_queue_Enqueue() to emulate
> >>> sleep() and
> >>> _Thread_queue_Flush_critical() to emulate wakeup(). Check all
> >>> critical sections that they can be protected by an ISR lock (no blocking
> >>> calls and short).
> >> Is this even so if pps_event() calls signal or broadcast? Because
> >> pps_fetch() is the only function that is waiting (and locking a
> mutex).
> > Do you mean something like this?
> >
> [...]
> >
> > Unfortunately something should be missing because it doesn't work.
>
> In cpukit/score/src/futex.c you have a working example.
>
> You would have to replace the mutex with the thread queue lock. I had a look
> at some FreeBSD drivers which use this stuff and it
> would not be possible to support them with this approach. You could move the
>
> if (abi_aware(pps, 1) && pps->driver_mtx != NULL) {
> if (pps->flags & PPSFLAG_MTX_SPIN) {
> err = msleep_spin(pps, pps->driver_mtx,
> "ppsfch", timo);
> } else {
> err = msleep(pps, pps->driver_mtx,
> PCATCH,
> "ppsfch", timo);
> }
> } else {
> err = tsleep(pps, PCATCH, "ppsfch", timo);
> }
>
> and
>
> /* Wakeup anyone sleeping in pps_fetch(). */
> wakeup(pps);
>
> blocks into RTEMS-specific sleep/wakeup callouts in struct pps_state.
>
Just reading this email a second time, do you mean stop trying the thread queue
approach and use another RTEMS-specific solution for waking up tasks which wait
in pps_fetch()? For example use RTEMS signals or events?
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
