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.
--
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
