(Cont.)
8-31
A MESSAGES safer, more efficient and more convenient method for thread communication via bounded buffer is to implement a new higher level system object message buffer: Implementation of Message Objects API library functions: HANDLE init_message_buffer(int N); void send(HANDLE h, Slot *x); void receive(HANDLE h, Slot *x); // Create a new message object // Send message // receive message
Trap handlers: // Message type (hidden in kernel) typedef struct { int N; int in, out; int count; Slot *B; BOOL lock; QUEUE mutex; QUEUE nonfull; QUEUE nonempty; BOOL guard; } Message_buffer; SEND: // // // // // // // // // Maximal number of slots Buffer pointers Number of slost placed into buffer Pointer to the buffer space CS lock to protect access to buffer Queue of thr. waiting to access the buff. Queue of thr. waiting for non-full cond. Queue of thr. waiting for non-empty cond. To protect lock, mutex, nonfull, nonempty
// prefix "p->" omitted for simplicity Disable interrupts; Get p = (Message_buffer *)h via register or stack; enter(mutex); if (count == N) wait(nonfull,mutex); enter(), wait() and B[in] = *x; in = (1+in)%N; signal() are internal kernel count++; functions, they are not called signal(nonempty,mutex); via TRAP, however they RTE; return via RTE (see next page) RECEIVE: Disable interrupts; Get p = (Message_buffer *)h via register or stack; enter(mutex); if (count == 0) wait(nonempty,mutex); *x = B[out]; out = (1+out)%N; count--; signal(nonfull,mutex); RTE;
Copyright 1998, 1999 by Marko Vuskovic
MESSAGES (Cont.)
8-32
enter(m): push(SR); while (tsl(guard)) {}; if (lock){ block(m); } else{ lock = TRUE; } guard = FALSE; RTE;
// Save status register // To protect lock
// Release spinlock
wait(c,m): push(SR); while (tsl(guard)) {}; running2blocked(c); if (queue m not empty) blocked2ready(m); else lock = FALSE; ready2running; guard = FALSE; RTE;
// Save status register // To protect lock
// Release spinlock
signal(c,m): push(SR); // Save status register while (tsl(guard)) {}; // To protect lock if( queue c not empty) unblock(c); else { if(queue m not empty) unblock(m); else lock = FALSE; } guard = FALSE; // Release spinlock RTE;
Copyright
1998, 1999 by Marko Vuskovic
MESSAGES (Cont.) FREQUENTLY ASKED QUESTION
8-33
Q1: Why we need to ensure mutual exclusion of buffer variables N, out, in, B[], count, lock...by using enter()? If we disable interrupts in traps SEND and RECEIVE, then no other thread can be scheduled while some thread is executing SEND or RECEIVE, therefore the mutual exclusion is already achieved. A1: That is true only for uniprocessor machines. In multiprocessor machines we must have enter(). Q2: Isn't it too dangerous to disable interrupts in SEND and RECEIVE? There is for example wait() which blocks the thread if the buffer is full/empty. The thread can be blocked until some other thread removes/puts slots from/into the buffer. A2: If a thread is blocked it doesn't mean that the execution is stuck in kernel. Blocking means updating and relinking the thread/process control blocks plus modifying the kernel stack (see pages 3-11 to 3-15). The RTE will make sure that the execution continues somewhere else without waiting for the bocking condition to be changed, i.e. that someone removes/puts a sloot from/to the buffer. Yes, Q3: but what if execution continues in kernel. That means, the interrupt is disabled during thread switching, which can be relatively long if the thread is outswapped? A3: True, this is a real danger if OS has virtual memory. Therefore Microsoft has introduced deferred procedure calls (DPC), (see chapter 12). Shortly, an interrupt service routine (ISR) has interrupts disabled only for a critical period of time, which is short enough and which doesn't cover the thread switching. Q4: Why we need to push processor status register (SR) onto kernel stack in kernel functions enter(), wait() and signal()? A4: Because these functions exit with RTE, there must be a correct balance on the kernel stack. Q5: Why do we need RTE in enter(), wait() and signal() anyway? These are functions, not traps and they are called by JSR (jump to subroutine), consequently they can exit with RTS (return from subroutine). Both, JSR and RTS push/pop only PC. A5: RTE doesn't necessarily mean that the execution will continue at the first instruction after the function call. The execution can continue in s some other thread. Essentially enter(), wait() and signal() do not follow FIFO principle, they behave more like coroutines. If the execution continues somewhere else, specially in user space, the user environment has to be restored, i.e. SR has to be restored.
Copyright 1998, 1999 by Marko Vuskovic
MESSAGES (Cont.) FREQUENTLY ASKED QUESTION (Cont.) Q6: Why the variable lock is not reset in than part of the outer if statement in signal()? If we are unblocking a thread we also need to make the critical section free for the unblocked thread. A6: The lock variable must be left TRUE. Consider signal(nonfull,mutex) in RECEIVE trap.
8-34
(a) Suppose that the unblocked thread (which was waiting due to a call of wait(nonfull,mutex)), gets running (unblock (nf) macro). This thread will continue execution imediately after the wait(nonfull,mutex) function call in SEND trap. Apparently, this thread won't have chance to set the lock variable, so it needs to be left TRUE. Same holds for signal(nonempty,mutex) in SEND trap. (b) Suppose now that the thread that called signal(nonfull,mutex) gets running (while the unblocked thread remains in ready queue). This thread will immediately leave the trap and return to the user space. Consequently noone is virtually in critical section and the lock variable is TRUE. That is however OK because the blocked thread will eventually get running, and we have the case (a). Q7: Why the variable lock is not reset in else part of the outer if statement in signal()? Like in Q6, we are leaving trap and critical section, therefore we need to reset the lock variable. A7: Answer is similar to A6. The only difference is that the other thread is blocked on enter(mutex) instead of wait(nonfull,mutex), and will continue execution after this call. The lock variable must therefore remain TRUE. Q8: Why do we need RTE at the end of SEND and RECEIVE traps? WE already have RTE at the end of signal(). A8: RTE in signal() and wait() exist for reason considered above. Eventually each call to SEND and RECEIVE trap will end up with PC loaded with address immediately after signal(). From there we need to return from the trap to the user space.
Copyright
1998, 1999 by Marko Vuskovic