[Repost] Globally disabling preemption
Manuel Coutinho
manuel.coutinho at edisoft.pt
Thu Nov 15 15:31:00 UTC 2007
Hi
>From my (limited) experience, thread A is guaranteed to run after the isr,
even if there are higher priority ready tasks.
In general, using RTEMS_NO_PREEMPT is a "good" solution IF you don't care
about interrupts, that is, if an ISR does not access the critical section.
I think however, that from a scheduling point of view (calculating the worst
schedulability analysis) this is a "bad" solution because this does not
integrate well with the mathematical analysis (don't remember any results
from heart where you protect a critical section this way). I think a
semaphore with priority inherence is a better way :).
(note that this also does not solve the interrupt problem I mentioned
earlier).
Regards
Manuel Coutinho
> -----Original Message-----
> From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org]
> On Behalf Of Keith Robertson
> Sent: Thursday, November 15, 2007 3:09 PM
> To: RTEMS mailing list
> Subject: [Repost] Globally disabling preemption
>
> [Rephrased question]
> Possibly a stupid question, however, it'd be great to confirm/clarify
> the following:
>
> Given a running RTEMS_NO_PREEMPT thread, A, is A guaranteed to run after
> an isr, regardless of any other threads the isr may make ready?
>
> In general, in rtems is it safe to use RTEMS_NO_PRREMPT
> enabling/disabling as mechanism of protecting a critical section from
> other threads?
>
> Cheers.
>
> Keith
>
> -------- Original Message --------
> Subject: Globally disabling preemption
> Date: Fri, 09 Nov 2007 15:32:03 +0000
> From: Keith Robertson <kjrobert at alumni.uwaterloo.ca>
> To: RTEMS mailing list <rtems-users at rtems.org>
>
> Hi.
>
> The rtems user guide states: "If preemption is disabled for a task
> (RTEMS_NO_PREEMPT), then the task will not relinquish control of the
> processor until it terminates, blocks, or re-enables preemption."
>
> Given an RTEMS_NO_PREEMPT thread A, I'd like to clarify what happens if
> A is interrupted (as interrupts are still on). When the scheduler runs
> at the end of an isr, what happens? Will A always be rescheduled? Or
> will the normal scheduling algorithm run and A may or may not be selected.
>
> I suspect it's the later. If this is the case, is there a recommended
> way of globally disabling preemption so as to have the effect of the
> former? That is, A is interrupted, but is always rescheduled after the
> interrupt.
>
> Cheers.
>
> Keith
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
More information about the users
mailing list