Changes between Version 81 and Version 82 of Developer/SMP

Timestamp:

04/21/14 23:04:56 (10 years ago)

Author:

Mayes

Comment:

/* Status of Effort */

Developer/SMP

@@ -57 +57 @@
 | [http://www.rtems.org/wiki/index.php/SMP#Tool_Chain Tool Chain] || TBD || 
 |-
-| [http://www.rtems.org/wiki/index.php/SMP#Profiling Profiling] || TBD || 
+| [http://www.rtems.org/wiki/index.php/SMP#Profiling Profiling] || TBD || CPU counter support is complete.  The profiling support is complete.
 |-
 | [http://www.rtems.org/wiki/index.php/SMP#Interrupt_Support_2 Interrupt Support] || TBD ||
 |-
-| [http://www.rtems.org/wiki/index.php/SMP#Clustered_Scheduling_2 Clustered Scheduling] || TBD || 
+| [http://www.rtems.org/wiki/index.php/SMP#Clustered_Scheduling_2 Clustered Scheduling] || Mostly complete || 
 |-
 | [http://www.rtems.org/wiki/index.php/SMP#Multiprocessor_Resource_Sharing_Protocol_-_MrsP  Multiprocessor Resource Sharing Protocol - MrsP] || TBD || 
@@ -67 +67 @@
 | [http://www.rtems.org/wiki/index.php/SMP#Fine_Grained_Locking Fine Grained Locking] || TBD || 
 |-
-| [http://www.rtems.org/wiki/index.php/SMP#Post-Switch_Actions Post-Switch Actions] || TBD || 
-|-
-| [http://www.rtems.org/wiki/index.php/SMP#Thread_Delete.2FRestart Thread Delete/Restart] || TBD || 
-|-
-| [http://www.rtems.org/wiki/index.php/SMP#Barrier_Synchronization Barrier Synchronization] || TBD || 
+| [http://www.rtems.org/wiki/index.php/SMP#Post-Switch_Actions Post-Switch Actions] || Complete || Implemented as post-switch thread-actions
+|-
+| [http://www.rtems.org/wiki/index.php/SMP#Thread_Delete.2FRestart Thread Delete/Restart] || Complete || 
+|-
+| [http://www.rtems.org/wiki/index.php/SMP#Barrier_Synchronization Barrier Synchronization] || Complete || 
 |-
 | [http://www.rtems.org/wiki/index.php/SMP#Low-Level_Broadcasts Low-Level Broadcasts] || TBD || 
@@ -1521 +1521 @@
 optimal interrupt latency with only constant-time sections of disabled
 interrupts.  The trade-off is that we have a very complex blocking sequence.
-After the first mutex state change in the mutex_obtain() the mutex doesn't know
-directly which thread is about to block on that mutex.  Some sequences assume
-exactly one executing
+After the first mutex state change in the m