CSE 451

1. CSE 451 Section 2/9 1

2. Agenda • Synchronization in Windows NT • Project Overview • Evaluation 2

3. Synchronization in Windows NT • No monitors • No condition variables • Some semaphores • What is there? • Mutexes • Events • Quasi-semaphores • Critical Sections 3

4. Syncronization in NT (2) • Objects have two states • Signaled: wait() completes immediately • Non-signaled: wait() blocks • WaitForSingleObject() waits on anything • Files • Processes • Threads (join) • Mutexes • Events • Semaphores 4

5. Synchronization in NT - Mutex • Mutexes • Kernel objects (expensive, but can be used in multiple processes) • State is signaled when not owned, and non-signaled when owned • FIFO queueing 5

6. Synchronization in NT – Event • Events • Kernel objects • Can be manual reset or auto reset • When auto-reset, only one thread is woken • Manual reset wakes all threads, but must be reset before it blocks threads unless PulseEvent() is used 6

7. Synchronization in NT – Semaphores • Sempahores • Like normal semaphores but: • Can’t have negative value • Value is limited • So: • Can’t do barrier synchronization (wait for n threads to signal) • Must know max size at initialization, so can’t grow dynamically 7

8. Synchronization in NT – Critical Sections • Critical sections • Like a mutex but: • Not necessarily kernel object, so faster • Can’t be used between threads • Allows busy waiting up to a preset count • If contention, automatically creates a mutex to wait on 8

9. Synchronization in NT (3) • What do people do? • Lots of critical sections • Lots of events • Release critical section when waiting on event, acquire it afterwards and perform test. Flag = false; While (!flag) { EnterCriticalSection(s); Flag = performTest(); LeaveCriticalSection(s); If (!Flag) WaitForSingleObject(e); } 9

10. Project 2 – User Programming • Four parts: • Implement system calls • Implement multiprogramming • Implement a fancy scheduler • Pass parameters between processes • The first two are the hard parts • These are not all independent, nor all dependent 10

11. User Programming Overview • User programs execute on a MIPS virtual machine • Instructions interpreted one at a time, time advances on each instruction • Has a separate address space from the kernel, so all addresses are translated • Currently, only one system call – Halt(), and one address space 11

12. System Calls • How do they work? • User program puts parameters in registers, system call ID in R2, executes syscall • Syscall instruction generates an exception • Machine::RaiseException calls ExceptionHandler • ExceptionHandler dispatches based on the exception type and the system call code 12

13. System Calls (2) • What do you have to do? • Make ExceptionHandler() call a system handler when it gets a system call exception • Make the system call handler call the appropriate system call with the appropriate parameters • Good - Use a Case statement • Better - Use a dispatch table • Trickiness: passing parameters • Update the PC before returning • See Narton’s roadmap • Add Machine::UpdatePC 13

14. System Calls (3) • Now that you’ve called the system call, then what? • Validate parameters • Pointers come in as virtual addresses, need to convert to physical addresses • Addresses are valid in callers address space • Other parameters are valid (I.e. strings are of finite length) • Perform function, return code in register • You need to create a set of return codes for failures, such as “file_not_found” etc. • Update PC 14

15. Multiprogramming • Allow multiple programs to run simultaneously • Need to preemptively switch between running programs • Each program has a separate address space • Need to be able to wait for a program to terminate - Join() • Need to synchronize AddrSpace so you can create multiple ones simultaneously • Allocate physical memory • Allocate address space ID numbers 15

16. Memory Management • AddrSpace object contains the translation • Currently, all of main memory is assigned to an address space. • pageTable[] structure contains the mapping – initially phys == virt • Memory is stored in Machine::mainMemory, addressed by physical address. • Translate.cc has the code to take a VA and translate it into a PA using the page table 16

17. Passing parameters • Modify exec() to take a parameter string • Main() is written in asm, so may want a system call to retrieve parameters • GetParams(char *buffer, int size) 17

18. Scheduling • Multi-level feedback queue • Pick your own parameters: • Time quantum • # of levels • Policy for moving between queues • Lottery scheduling (lecture 11, 99au) • SJF is optimal but unfair (long jobs starve) • MLF isn’t fair if some queues have more jobs • Idea: give lottery tickets to jobs 18

19. Lottery Scheduling • Give each job some # of tickets • Each job gets at least one • On each slice, randomly pick the winning ticket. • Ticket assignment: • Short jobs get more tickets • Long jobs get few tickets • Ticket transfer: • Priority inversion handled by transferring tickets to resource owner 19

20. Lottery Scheduling Example • Suppose short jobs get 10 tickets and long jobs get 1 ticket 20

21. Testing • Good tests report whether they pass or fail • They can tell if they succeeded • They report back what happened • E.g for threads: predict the order of finishing • For system calls, you should test bad parameters • Bad pointers • Null strings • Strings without null terminators • Values for “size” that are bigger than “buffer” • Boundaries: buffers that cross the edge of a page. 21

22. Evaluation • For my use, not the University’s • Any comments will directly benefit you 22