1 / 22

CSE 451

CSE 451. Section 2/9. Agenda. Synchronization in Windows NT Project Overview Evaluation. Synchronization in Windows NT. No monitors No condition variables Some semaphores What is there? Mutexes Events Quasi-semaphores Critical Sections. Syncronization in NT (2).

etoile
Download Presentation

CSE 451

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related