On Mon, Apr 26, 2021 at 1:36 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> On 26/04/2021 20:30, Gedare Bloom wrote: > > > I need clarification on a subtle point, which exists prior to your > > change. It may be that I just don't understand what we mean by "The > > directive will not cause the calling task to be preempted.", but does > > rtems_interrupt_enable() and rtems_interrupt_flash() introduce a > > preemption point? The documentation suggests it does not, but I am not > > so clear. What about rtems_interrupt_lock_acquire() and > > rtems_interrupt_lock_release()? Similar kind of thinking applies. > > Calling these directives can cause a scheduling invocation due to, for > > example, a deferred clock tick interrupt or a block/unblock operation. > > This can cause the task to be preempted? Or do I misunderstand. > Maybe we should give a hint, that enabling maskable interrupts may > result immediately in an interrupt service which may result in a > preemption of the calling task. Strictly, this preemption is not done by > the calling task. The calling task doesn't invoke the scheduler or > perform a thread dispatch directly. > Gedare and I chatted about this and this was my explanation. It you wrote a test to see a preemption as a side-effect of enable/flash, it would fail because it does not directly cause one. On a SMP system with the synchronization to disable interrupts on all cores, I assume this also holds. A hint is definitely worth providing. The same logic applies to any method. If you get an interrupt while in it, you could get preempted while the method doesn't directly cause the preemption. --joel > > -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
