Program Design Issues and Weaknesses

The following hit-list identifies potential weaknesses in program design that can lead to hang symptoms or serialisation problems:

• Manipulation of thread priorities for the purpose of serialisation or sequencing execution is haphazard at best. At worst the performance of the entire system can be jeopardised.

  The following guidelines should be applied when considering priority manipulation:

  • Use priority delta to tell the system the relative importance of an application's threads.

  • Avoid priority class manipulation. Priority class tends to specify the relative importance of a thread with respect to all other threads in the system.

  • Avoid the use of time-critical priority. By setting this class, a thread is assuming the position of utmost importance in the system. This may not be a valid assumption for some system configurations and some users.

  • If priority class manipulation is desirable under some circumstances, then it should be parameterised so that it can be controlled as an option by the user.
  2.
  If a window of exposure exists it will be exposed.
  3.
  Any common resource that is ever modified must have an associated lock or serialisation mechanism.
  4.
  Locks (serialisation techniques such as semaphores) that are concurrently held and waited on must be obtained in an established order.
  5.
  Simplistic approach (one lock) forces work to be channelled through a single-queue. Therefore design locks at the lowest level of contention.
  6.
  Distinguish process/data/repository serialisation otherwise an inconsistent system of locks may result:

  • Process locks are required where a only single instance of a process is allowed to operate. For example:

    Finite State Machine state transitions;

    Some FSM state users;

    Any non-reentrant process.

    
    Distinguishing Repository locks allows the repository is updated:

    disk/directory reorganisation while file data is in use.

    physical page assignments are allowed to change while data is in use - swapping

    7.
    Data optimisation: Artificial association of unrelated data items imposes serialisation constraints that will have two possible effects:

    • This necessitates unrelated processes to serialise.

    • Serialisation may lead to unavoidable deadlocks.
    8.
    Code optimisation: imposes process lock constraints in a similar way that data optimisation does.
    9.
    O-O tends to hide the data repository and structure. May even hide the process. Therefore designers need to consider whether locks are managed internally, within the object or explicitly. It may not be possible to handle the locks internally, because the context in which an instance method is being use (that is, the process) is not discernible from within the object.

    ---

    [Back: Priority Inversion]
    [Next: Worked Examples]