Protected and Unprotected operations on Chain_control

[Gedare Bloom]

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 <gadia at 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 <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
>
>