Protected and Unprotected operations on Chain_control

[Saurabh Gadia]

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 <gedare at gwu.edu> wrote:

> On Wed, Aug 12, 2015 at 11:48 AM, Saurabh Gadia <gadia at 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 at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150812/e646335e/attachment-0002.html>