Changes between Version 14 and Version 15 of Developer/SMP

Jan 13, 2014, 2:29:45 PM (6 years ago)

/* Design Issues */


  • Developer/SMP

    v14 v15  
    240240on single processor configurations.  On SMP configurations they use an SMP lock
    241241to ensure mutual exclusion throughout the system.
    242 =  = Future Directions ====
     242==  Future Directions  ==
    245245 *  See [wiki:#SMP_Locks  SMP locks].
    246246 *  Ensure via a RTEMS assertion that normal interrupt disable/sequences are only used intentional outside of the Giant lock critical sections.  Review usage of ISR disable/enable sequences of the complete code base.
    247 =  = Implementation ==
    250 == Testing ==
     247=  Giant Lock vs. Fine Grained Locking  =
     249==  Status  ==
     252The operating system state is currently protected by three things
     254 *  the per-processor thread dispatch disable level,
     255 *  the Giant lock (a global recursive SMP lock), and
     256 *  the disabling of interrupts.
     258For example the operating services like ''rtems_semaphore_release()'' follow this
     261 operation(id):
     262        disable_thread_dispatching()
     263        acquire_giant_lock()
     264        obj = get_obj_by_id(id)
     265        status = obj->operation()
     266        put_object(obj)
     267        release_giant_lock()
     268        enable_thread_dispatching()
     269        return status
     271All high level operations are serialized due to the Giant lock.  The
     272introduction of the Giant lock allowed a straight forward usage of the existing
     273single processor code in an SMP configuration.  However a Giant lock will
     274likely lead to undesirable high worst case latencies which linear increase with
     275the processor count <ref name="Brandenburg2011">Björn B. Brandenburg, Scheduling and Locking in Multiprocessor Real-Time Operating Systems, 2011.</ref>.
     276==  Future Directions  ==
     279The Giant lock should be replaced with fine grained locking.  In order to
     280introduce fine grained locking the state transitions inside a section protected
     281by the Giant lock must be examined.  As an example the event send and receive
     282operations are presented in a simplified state diagram.
     284[wiki:File:rtems-smp-events.png 645x600px]
     286The colour indicates which locks are held during a state and state transition.
     287In case of a blocking operation we have four synchronization states which are
     288used to split up the complex blocking operation into parts in order to decrease
     289the interrupt latency
     291 *  nothing happened,
     292 *  satisfied,
     293 *  timeout, and
     294 *  synchronized.
     296This state must be available for each thread and resource (e.g. event,
     297semaphore, message queue).  Since this would lead to a prohibitive high memory
     298demand and a complicated implementation some optimizations have been performed
     299in RTEMS.  For events a global variable is used to indicate the synchronization
     300state.  For resource objects the synchronization state is part of the object.
     301Since at most one processor can execute a blocking operation (ensured by the
     302Giant lock or the singe processor configuration) it is possible to use the
     303state variable only for the executing thread.
     305In case one SMP lock is used per resource the resource must indicate which
     306thread is about to perform a blocking operation since more than one executing
     307thread exists.  For example two threads can try to obtain different semaphores
     308on different processors at the same time.
     310A blocking operation will use not only the resource object, but also other
     311resources like the scheduler shared by all threads of a dispatching domain.
     312Thus the scheduler needs its own locks.  This will lead to nested locking and
     313deadlocks must be prevented.
     314=  Implementation  =
     316=  = Testing ==