X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=src%2Fthreads%2Fthread.h;h=d6a3990f1047d795b4255efa278af5f1a1119e32;hb=f2f8875638593bd5365cfd6a5ba7c9578e52322f;hp=e8927def25ebc99594a541425096ddc6eff8c4e4;hpb=349cc721b17effa62c8b18a7dccc5defc44472d3;p=pintos-anon diff --git a/src/threads/thread.h b/src/threads/thread.h index e8927de..d6a3990 100644 --- a/src/threads/thread.h +++ b/src/threads/thread.h @@ -1,35 +1,92 @@ #ifndef HEADER_THREAD_H #define HEADER_THREAD_H 1 +#include +#include #include -#include "debug.h" -#include "list.h" #ifdef USERPROG -#include "addrspace.h" +#include "userprog/addrspace.h" #endif -enum thread_status +/* States in a thread's life cycle. */ +enum thread_status { - THREAD_RUNNING, - THREAD_READY, - THREAD_BLOCKED, - THREAD_DYING + THREAD_RUNNING, /* Running thread. */ + THREAD_READY, /* Not running but ready to run. */ + THREAD_BLOCKED, /* Waiting for an event to trigger. */ + THREAD_DYING /* About to be destroyed. */ }; -struct thread +/* A kernel thread or user process. + + Each thread structure is stored in its own 4 kB page. The + thread structure itself sits at the very bottom of the page + (at offset 0). The rest of the page is reserved for the + thread's kernel stack, which grows downward from the top of + the page (at offset 4 kB). Here's an illustration: + + 4 kB +---------------------------------+ + | kernel stack | + | | | + | | | + | V | + | grows downward | + | | + | | + | | + | | + | | + | | + | | + | | + +---------------------------------+ + | magic | + | : | + | : | + | name | + | status | + 0 kB +---------------------------------+ + + The upshot of this is twofold: + + 1. First, `struct thread' must not be allowed to grow too + big. If it does, then there will not be enough room for + the kernel stack. Our base `struct thread' is only a + few bytes in size. It probably should stay well under 1 + kB. + + 2. Second, kernel stacks must not be allowed to grow too + large. If a stack overflows, it will corrupt the thread + state. Thus, kernel functions should not allocate large + structures or arrays as non-static local variables. Use + dynamic allocation with malloc() or palloc_get() + instead. + + The first symptom of either of these problems will probably be + an assertion failure in thread_current(), which checks that + the `magic' member of the running thread's `struct thread' is + set to THREAD_MAGIC. Stack overflow will normally change this + value, triggering the assertion. */ +/* The `elem' member has a dual purpose. It can be an element in + the run queue (thread.c), or it can be an element in a + semaphore wait list (synch.c). It can be used these two ways + only because they are mutually exclusive: only a thread in the + ready state is on the run queue, whereas only a thread in the + blocked state is on a semaphore wait list. */ +struct thread { /* These members are owned by the thread_*() functions. */ enum thread_status status; /* Thread state. */ char name[16]; /* Name (for debugging purposes). */ uint8_t *stack; /* Saved stack pointer. */ - list_elem rq_elem; /* Run queue list element. */ + list_elem elem; /* List element. */ #ifdef USERPROG /* These members are owned by the addrspace_*() functions. */ uint32_t *pagedir; /* Page directory. */ #endif - + /* Marker to detect stack overflow. */ unsigned magic; /* Always set to THREAD_MAGIC. */ };