[Repost] Globally disabling preemption

[Manuel Coutinho]

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