thread dispatch occurs due to an interrupt. if interrupts are disabled, then no dispatch.
On Wed, Aug 12, 2015 at 2:23 PM, Saurabh Gadia <ga...@usc.edu> wrote: > Hi, > > #define _ISR_Disable( _level ) \ > do { \ > _CPU_ISR_Disable( _level ); \ > _Assert( _Debug_Is_owner_of_giant() ); \ > RTEMS_COMPILER_MEMORY_BARRIER(); \ > } while (0) > > the above macro has description: > > @brief Disables interrupts on this processor. > * > * This macro disables all interrupts on this processor so that a critical > * section of code is protected from concurrent access by interrupts of > this > * processor. Disabling of interrupts disables thread dispatching on the > * processor as well. > * > * On SMP configurations other processors can enter such sections if not > * protected by other means. > * > * @param[out] _level The argument @a _level will contain the previous > * interrupt mask level. > */ > > And : > #define _ISR_Disable_without_giant( _level ) \ > do { \ > _CPU_ISR_Disable( _level ); \ > RTEMS_COMPILER_MEMORY_BARRIER(); \ > } while (0) > > The above lock is acquired for SMP. > > But how are both macros different. With former Macro it disables all > interrupts as level is highest but how does it ensure > thread_dispatch_disable? > > > Thanks, > > Saurabh Gadia > > On Wed, Aug 12, 2015 at 9:52 AM, Gedare Bloom <ged...@gwu.edu> wrote: >> >> On Wed, Aug 12, 2015 at 11:48 AM, Saurabh Gadia <ga...@usc.edu> wrote: >> > Hi, >> > >> > For operations related to manipulation of Chain_Node we have two modes >> > for >> > that: protected and unprotected. In protected access to chain we guard >> > the >> > operation by disabling the interrupts while in unprotected we don't >> > guard >> > it. Is it that we don't disable interrupts in unprotected mode because >> > we >> > are sure that ISR will not affect the operation and with protected ISR >> > may >> > affect the operation so we guard operation against it. When is protected >> > and >> > unprotected used in respect with the context? >> > >> Correct. "unprotected" means something else has already ensured mutual >> exclusion. >> >> > Thanks, >> > >> > Saurabh Gadia >> > >> > _______________________________________________ >> > 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