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