[Bug 1876] Add SMP ISR support

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1876

Sebastian Huber <sebastian.huber at embedded-brains.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sebastian.huber at embedded-br
                   |                            |ains.de

--- Comment #9 from Sebastian Huber <sebastian.huber at embedded-brains.de> 2011-08-23 02:39:31 CDT ---
Single processor RTEMS systems require one hardware mechanism to ensure
protection of critical sections against concurrent access. Concurrent access in
a single processor system can only occur due to interrupts. Thus the protection
mechanism is disabling and enabling of interrupts. The high level
synchronization
primitives like events, semaphores, mutexes, barriers, message queues, etc. are
based on such critical sections.

The _ISR_Disable/Enable/Flash is something like a big kernel lock.

In the SMP context the macro names are a bit misleading, but I think it is more
confusing if we change _ISR_Disable/Enable/Flash to something like
_Giant_Lock/Unlock/Unlock_and_lock.

Do I understand it right that this change does the following?

1. _ISR_Disable/Enable/Flash is now the big kernel lock.
2. _ISR_Disable/Enable/Flash_on_this_core disables the interrupts on this core.

If this is true, then code that was written with interrupt/task synchronization
in mind leads now to critical sections for the overall system on a SMP machine.
 This is all right, since code written for a single processor cannot know that
it may run now on one core and get the interrupts on another core.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.