AW: AW: AW: Dependencies of PPS API in rtems-libbsd

[Gabriel.Moyano at dlr.de]

> On 30/03/2022 15:19, Gabriel.Moyano at 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?