In embedded systems it's common for access to critical system structures to be protected by disabling and the enabling interrupts so that interrupt service routines are not executed during the update. You can write your own code to do this using the __disable_interrupt and __set_interrupt intrinsic functions like this:

    void update_critical_resource(void)
    {
      // Disable interrupts and save previous interrupt enable state
      unsigned state = __disable_interrupt();

      // Update your critical resource here...
      task_list = task_list->next; // just an example

      // Restore interrupt state on entry
      __set_interrupt(state);
    }

If you disabled and enabled interrupts using __disable_interrupt and __enable_interrupt, rather than using __disable_interrupt and __set_interrupt as above, calling the function with interrupts disabled would re-enable interrupts on return which is usually not what you want. If you write your code in the same fashion as above you can call the function and be sure that it's run with interrupts disabled and that on return the interrupt enable state is as it was before the call.

Because this type of function is so common, CrossWorks provides the __monitor keyword. Using __monitor the example above becomes:

    void update_critical_resource(void) __monitor
    {
      // Update your critical resource here...
      task_list = task_list->next; // just an example
    }

The compiler generates better code using the __monitor compares to using the __disable_interrupt and __set_interrupt intrinsic functions.