doc/README.sched

   1 Notes on the scheduler in sched.c:
   2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   3
   4   'sched.c' provides an very simplistic multi-threading scheduler.
   5    See the example, function 'sched(...)', in the same file for its
   6    API usage.
   7
   8    Until an exhaustive testing can be done, the implementation cannot
   9    qualify as that of production quality. It works with the example
  10    in 'sched.c', it may or may not work in other cases.
  11
  12
  13 Limitations:
  14 ~~~~~~~~~~~~
  15
  16   - There are NO primitives for thread synchronization (locking,
  17     notify etc).
  18
  19   - Only the GPRs and FPRs context is saved during a thread context
  20     switch. Other registers on the PowerPC processor (60x, 7xx, 7xxx
  21     etc) are NOT saved.
  22
  23   - The scheduler is NOT transparent to the user. The user
  24     applications must invoke thread_yield() to allow other threads to
  25     scheduler.
  26
  27   - There are NO priorities, and the scheduling policy is round-robin
  28     based.
  29
  30   - There are NO capabilities to collect thread CPU usage, scheduler
  31     stats, thread status etc.
  32
  33   - The semantics are somewhat based on those of pthreads, but NOT
  34     the same.
  35
  36   - Only seven threads are allowed. These can be easily increased by
  37     changing "#define MAX_THREADS" depending on the available memory.
  38
  39   - The stack size of each thread is 8KBytes. This can be easily
  40     increased depending on the requirement and the available memory,
  41     by increasing "#define STK_SIZE".
  42
  43   - Only one master/parent thread is allowed, and it cannot be
  44     stopped or deleted. Any given thread is NOT allowed to stop or
  45     delete itself.
  46
  47   - There NOT enough safety checks as are probably in the other
  48     threads implementations.
  49
  50   - There is no parent-child relationship between threads. Only one
  51     thread may thread_join, preferably the master/parent thread.
  52
  53 (C) 2003 Arun Dharankar <ADharankar@ATTBI.Com>