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