
According to hofmeister:

1) Without the participation of the modules being reconfigured. It's doable when

  a) module state can be lost
  b) modules can start execution without external knowledge
  c) there's no synchronization between the reconfigurable module and
     its neighbors.


2) With the participation of the modules being reconfigured.

  a) State must be transfered.
     i) Modules implement encode and decode operations to manipulate
        "serialized" state. The framework uses these operations.
     ii) the modules interact and exchange state directly.

  b) Need stable states for reconfiguration.
     i) Use checkpointing and roll-back to the last checkpoint. 
        This is expensive because it requires periodic checkpointing, i.e.,
        saving the module state from time to time.
     ii) Continue running until the next stable state is achieved.
         The overhead of saving module state just occurs when a
         reconfiguration is requested. The problem is that if something fails
         or if it is not correctly programmed, a stable state may never be reached.

3) Types of reconfiguration.

   a) Module replacement.
      Module participation is limited to capturing and restoring local state.
   b) Module migration
      Module participation is limited to moving local state.
   c) Structural change.
      Module participation may required global state information.

