DOCSLIB.ORG

Semaphores Cosc 450: Programming Paradigms 06

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Semaphores Cosc 450: Programming Paradigms 06 CoSc 450: Programming Paradigms 06 Semaphores CoSc 450: Programming Paradigms 06 Semaphore Purpose: To prevent inefficient spin lock of the await statement. Idea: Instead of spinning, the process calls a method that puts it in a special queue of PCBs, the “blocked on semaphore” queue. 71447_CH08_Chapter08.qxd 1/28/09 12:27 AM Page 422 422 Chapter 8 Process Management The PCB contains additional information to help the operating system schedule the CPU. An example is a unique process identification number assigned by the system, labeled Process ID in Figure 8.18, that serves to reference the process. Sup- pose a user wants to terminate a process before it completes execution normally, and he knows the ID number is 782. He could issue a KILL(782) command that would cause the operating system to search through the queue of PCBs, find the PCB with ID 782, remove it from the queue, and deallocate it. Another example of information stored in the PCB is a record of the total amount of CPU time used so far by the suspended process. If the CPU becomes available and the operating system must decide which of several suspended processes gets the CPU, it can use the recorded time to make a fairFigure decision. 8.19 As a job progresses through the system toward completion, it passes through several states, as Figure 8.19 shows. The figure is in the form of a state transition diagram and is another example of a finite state machine. Each transition is labeled with the event that causes the change of state. Waiting Figure 8.19 for I/O The state transition diagram for a I/O complete I/Orequest job in an operating system. Select to run Start Ready Running Finish Create Terminate Time out process process When a user submits a job for processing, the operating system creates a process for it by allocating a new PCB and attaching it to a queue of processes that are waiting for CPU time. It loads the program into main memory and sets the copy of PC in the PCB to the address of the first instruction of the process. That puts the job in the ready state. Eventually, the operating system should select the job to receive some processing time. It sets the alarm clock to generate an interrupt after a quantum of time and puts the copies of the registers from the PCB into the CPU. That puts the job in the running state. While in the running state, three things can happen: (1) The running process Transitions from the running state may time out if it is still executing when the alarm clock interrupts. If so, the oper- ating system attaches the process’s PCB to the ready queue, which puts it back in the ready state. (2) The process may complete its execution normally, in which case the last instruction it executes is an SVC to request that the operating system termi- nate it. (3) The process may need some input, in which case it executes an SVC for the request. The operating system would transfer the request to the appropriate I/O device and put the PCB in another queue of processes that are waiting for their I/O operations to complete. That puts the process in the waiting-for-I/O state. CoSc 450: Programming Paradigms 06 Add fourth state for a process 1. Ready in the ready queue 2. Running in the cpu 3. Waiting for I/O in the I/O-wait queue 4. Blocked in the blocked-on-semaphore queue Figure 8.29 Waiting for I/O I/O complete I/O request Select to run Start Ready Running Finish Create Terminate Time out process process signal(s) Waiting wait(s) for s State Changes of a Process - ª - inactive ready - running completed HY H HH ? HH H blocked M. Ben-Ari. Principles of Concurrent and Distributed Programming, Second edition c M. Ben-Ari 2006 Slide 6.1 ≠ p2 p8 turn = 2 ∧ ¬ ⇒ ¬ ! " turn = 2 " ⇒# $ p6 !" p3..5 p8..10 want p ⇒# ∨ ≡ $ want p CoSc 450: Programming¬ Paradigms 06 !" ⇒# $ q9 ! ⇒# ← $ turn = 1Semaphore type Semaphore! S hasturn two= 2 fields: " S.V S.L CoSc 450: Programming Paradigms 06 Semaphore atomic operations Memorize this p2 p8 turn = 2 ∧ ¬ ⇒ ¬ ! " turn = 2 " ⇒# $ p6 !" p3..5 p8..10 want p ⇒# ∨ ≡ $ want p ¬ !" ⇒# $ q9 ! ⇒# ← $ turn = 1 ! turn = 2 " CoSc 450: Programming S .ParadigmsV 06 Semaphore Satomic.L operations Memorize this S (k, /0 ) ← wait(S) S.V > 0 S.V S.V 1 ← − S.L S.L p ← ∪ p.state ← signal(S) S.L = /0 S.V S.V + 1 ← q S.L S.L S.L q ← − { } q.state ← p2 p8 turn = 2 ∧ ¬ ⇒ ¬ ! " p2 p8 turn = 2 ∧ ¬ ⇒ ¬ turn = 2 ! " " ⇒# $ turn = 2 p6 " ⇒# !"$ p3..5 p8..10 want p p6 ⇒# ∨ ≡ $ want p !" p3..5 p8..10 want¬ p ⇒# ∨ ≡!"$ want p ⇒# $ ¬ q9 !" ⇒# ! $ q9 ⇒# ← $ = ! turn 1 ⇒# ← $ turn = 1 ! turn = 2 ! turn = 2 " CoSc 450: Programming S .ParadigmsV 06 " S.V Semaphore Satomic.L operations S.L Memorize this S (k, /0 ) ← S (k, /0 ) ← wait(S) wait(S) S.V > 0 S.V > 0 S.V S.V 1 S.V S.V 1 ← − ← − S.L S.L p S.L S.L p ← ∪ ← ∪ p.state p.state ← ← signal(S) signal(S) S.L = /0 S.L = /0 S.V S.V + 1 S.V S.V + 1 ← ← q S.L q S.L S.L S.L q S.L S.L q ← − { } ← − { } q.state q.state ← ← p2 p8 turn = 2 ∧ ¬ ⇒ ¬ ! " turn = 2 " ⇒# $ p6 p2 p8 turn = 2 ∧ ¬ ⇒ !"¬ p3..5 p8..10 want p ! ⇒#" ∨ ≡ $ want p p2 p8 turn = 2 ¬ ∧ ¬ ⇒ ¬ turn = 2 !" ! " ⇒# $ " q9 ⇒# $ turn = 2 p6 ! " ⇒# ← $ ⇒# !"$ p3..5 turnp8..=101 want p p6 ⇒# ∨ ≡ $ want p! turn = 2 !" p3..5 p8..10 want¬ p ⇒# ∨ ≡!"$ " want p ⇒# S.V $ ¬ q9 !" ⇒# ! $ S.L q9 ⇒# ← $ = ! turn 1 ⇒# ← $ turn = 1 ! turn = 2 ! turn = 2 " S (k, /0 ) CoSc 450: Programming S .ParadigmsV ← 06 " S.V Semaphore Satomic.L wait operations(S) S.L Memorize this S.V > 0 S.V S.V 1 ← − S (k, /0 )S.L S.L p ← ← ∪ S (k, /0 ) p.state ← ← wait(S) wait(S) S.V >signal0 (S) S.V > 0 S.V S.SV.L =1 /0 S.V S.V 1 ← −S.V S.V + 1 ← − ← S.L S.L p S.L S.L p ← ∪ q S.L ← ∪ p.state p.state ← S.L S.L q ← − { } ← q.state signal(S) ← signal(S) S.L = /0 S.L = /0 S.V S.V + 1 S.V S.V + 1 ← ← q S.L q S.L S.L S.L q S.L S.L q ← − { } ← − { } q.state q.state ← ← CoSc 450: Programming Paradigms 06 Binary semaphore The value S.V is only allowed to be 0 or 1. Also called “mutex” for mutual exclusion. CoSc 450: Programming Paradigms 06 Critical section The critical section problem is trivial when you have semaphores. Algorithm 6.1: Critical section with semaphores (two processes) binary semaphore S (1, ) ¿ ; p q loop forever loop forever p1: non-critical section q1: non-critical section p2: wait(S) q2: wait(S) p3: critical section q3: critical section p4: signal(S) q4: signal(S) M. Ben-Ari. Principles of Concurrent and Distributed Programming, Second edition c M. Ben-Ari 2006 Slide 6.2 ≠ p2 p8 turn = 2 ∧ ¬ ⇒ ¬ ! " turn = 2 " ⇒# $ p6 !" p3..5 p8..10 want p p2 p8 turn = 2 ⇒# ∨ ≡ $ ∧ ¬ ⇒ ¬ want p ¬ ! " !" ⇒# $ turn = 2 q9 " ! ⇒# $ ⇒# ← $ p6 turn = 1 !" p3..5 p8..10 want p! turn = 2 ⇒# ∨ ≡ $ want p " ¬ S.V !" ⇒# $ CoScq 9450: Programming Paradigms S.L 06 ! ⇒# ← $ Class exercise turn = 1 Construct the first part of the state transition diagram: ! turn = 2 S (k, /0 ) p, p, q, q, p, p," (p and q), ... ← S.V wait(S) Algorithm 6.1: Critical section with semaphores (two processes) S.L binary semaphore S (1, ) . > ¿ ;S V 0 p S.V q S.V 1 loop forever loop forever ← − p1: non-critical section q1: non-critical section p2: wait(S) q2: wait(S)S.L S.L p ← ∪ p3: criticalS section(k, /0 ) q3: criticalp section.state p4: signal(S)← q4: signal(S) ← wait(S) signal(S) S.V > 0 S.L = /0 S.V S.V + 1 S.V S.V 1 ← ← − M. Ben-Ari. Principles of Concurrent and Distributed Programming, Second edition c M. Ben-Ari 2006 Slide 6.2 . S.L S.L p ≠q S L ← ∪ S.L S.L q p.state ← − { } ← q.state ← signal(S) S.L = /0 S.V S.V + 1 ← q S.L S.L S.L q ← − { } q.state ← p1,q1 (1, /0 ) p1,q1 p2,q1 p1,q1 (1, /0 ) (1, /0 ) (1, /0 ) p2,q1 p2,q1 p3,q1 (1, /0 ) (0, /0 ) (1, /0 ) p1,q1 p3,q1 (1, /0 ) p1,q1 p3,q2 p(03,,/0q)1 (1, /0 ) (0, /0 ) (0, /0 ) p2,q1 p3,q2 p1,q1 (p11, ,/0 q) 1 p2,q1 p3,q3 p(03,,/0q)2 (1, /0 ) ! (1, /0 ) (1, /0 ) (0, q ) (0, /0 ) p3,q1 p2,q1 { } p3,q3! p1,q1 (p02, ,/0 q) 1 (p13,,/0 q)1 (0, q ) p4,q3! p3,q3! (1, {/0 ) } p(31,,q/0 2) (0, /0 ) A (0, q ) B (0, q ) C D p3,q1 { } p4,{q3}! (0, /0 ) p1,q1 p p2,q1 p p3,q1 q (p03,,/0 q)2 (0, q ) p(11,,/0q)3 p4,q3! (1, {/0 ) } p(30,,q/0 3)! (p03,,q/0 )2 (0, /0 ) (0, q ) p1,{q3} (0, q ) (0, /0 )q p2,q1 p3,q1 F p3{,q}2 E p3,q3! (0, /0 ) p(12,,/0q)3 p (p01,,/0 q)3 p p(40,,q/0 3)! p (p03,,qq3! ) { } (0, /0 ) (0, q ) (0, q ) (0, /0 ) p2,q3 { } { } p3,q1 p3,q2 p3,q3 p4,q3! (0, /0 q) ! (0, /0 ) (0, /0 ) p(1,,q3q ) (p04,,qq3! ) p1,q4 p2,q3 0 { } (0, /0 {) } (0, q ) (0, /0 ) (p01,,/0q)4 { } p3,q2 p3,q3! p4,q3! p1,q3 (0, /0 ) p ,q p1,q3 (0, /0 ) (0, q ) (20, 3q ) (0, /0 ) p1,{q4} (0, /0 {) } (0, /0 ) p3,q3 (0, /0 ) States !E and F havep4,q no3! transitionp1 on,q3 q becausep q2, ,isqq 3 p1,q4 2 3 blocked.(0, q ) q3’ means(0, qq3) cannot execute.(0, /0 ) (00,,/0 /0 )) { } { } (0, /0 ) p4,q3! p1,q3 p2,q3 p11,,qq44 (0, q ) (00,,/0 /0 )) { } (0, /0 ) (0, /0 ) p1,q3 p2,q3 p1,q4 (0, /0 ) (0, /0 ) (0, /0 ) p2,q3 p1,q4 (0, /0 ) (0, /0 ) p1,q4 (0, /0 ) p2 p8 turn = 2 ∧ ¬ ⇒ ¬ ! " turn = 2 " ⇒# $ p6 !" p3..5 p8..10 want p p2 p8 turn = 2 ⇒# ∨ ≡ $ ∧ ¬ ⇒ ¬ want p ! " ¬ !" ⇒# $ turn = 2 q9 " ! ⇒# $ ⇒# ← $ p6 turn = 1 !" p3..5 p8..10 want p! turn = 2 ⇒# ∨ ≡ $ want p " ¬ S.V !" ⇒# $ CoScq 9450: Programming Paradigms S.L 06 ! ⇒# ← $ turn = 1 Class exercise ! turn = 2 Construct the complete state transitionS ( kdiagram, /0 ) " ← S.V Algorithm 6.2: Critical section withwait semaphores(S) (two proc., abbrev.) S.L binary semaphore S (1S, .V) > 0 ¿ ; p S.V S.Vq 1 ← − loop forever loop forever p1: wait(S) q1: wait(S)S.L S.L p ← ∪ p2: signal(S) S (k, /0 ) q2: signal(S)p.state ← ← wait(S) signal(S) S.V > 0 S.L = /0 S.V S.V + 1 S.V S.V 1 ← ← − S.L S.L p q S.L ← ∪ S.L S.L q p.state ← − { } M.
Load more

Recommended publications
  • An Introduction to Linux IPC
    An introduction to Linux IPC Michael Kerrisk © 2013 linux.conf.au 2013 http://man7.org/ Canberra, Australia [email protected] 2013-01-30 http://lwn.net/ [email protected] man7 .org 1 Goal ● Limited time! ● Get a flavor of main IPC methods man7 .org 2 Me ● Programming on UNIX & Linux since 1987 ● Linux man-pages maintainer ● http://www.kernel.org/doc/man-pages/ ● Kernel + glibc API ● Author of: Further info: http://man7.org/tlpi/ man7 .org 3 You ● Can read a bit of C ● Have a passing familiarity with common syscalls ● fork(), open(), read(), write() man7 .org 4 There’s a lot of IPC ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memory attach ● Pseudoterminals ● proc_vm_readv() / proc_vm_writev() ● Sockets ● Signals ● Stream vs Datagram (vs Seq. packet) ● Standard, Realtime ● UNIX vs Internet domain ● Eventfd ● POSIX message queues ● Futexes ● POSIX shared memory ● Record locks ● ● POSIX semaphores File locks ● ● Named, Unnamed Mutexes ● System V message queues ● Condition variables ● System V shared memory ● Barriers ● ● System V semaphores Read-write locks man7 .org 5 It helps to classify ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memory attach ● Pseudoterminals ● proc_vm_readv() / proc_vm_writev() ● Sockets ● Signals ● Stream vs Datagram (vs Seq. packet) ● Standard, Realtime ● UNIX vs Internet domain ● Eventfd ● POSIX message queues ● Futexes ● POSIX shared memory ● Record locks ● ● POSIX semaphores File locks ● ● Named, Unnamed Mutexes ● System V message queues ● Condition variables ● System V shared memory ● Barriers ● ● System V semaphores Read-write locks man7 .org 6 It helps to classify ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memoryn attach ● Pseudoterminals tio a ● proc_vm_readv() / proc_vm_writev() ● Sockets ic n ● Signals ● Stream vs Datagram (vs uSeq.
    [Show full text]
  • Multithreading Design Patterns and Thread-Safe Data Structures
    Lecture 12: Multithreading Design Patterns and Thread-Safe Data Structures Principles of Computer Systems Autumn 2019 Stanford University Computer Science Department Lecturer: Chris Gregg Philip Levis PDF of this presentation 1 Review from Last Week We now have three distinct ways to coordinate between threads: mutex: mutual exclusion (lock), used to enforce critical sections and atomicity condition_variable: way for threads to coordinate and signal when a variable has changed (integrates a lock for the variable) semaphore: a generalization of a lock, where there can be n threads operating in parallel (a lock is a semaphore with n=1) 2 Mutual Exclusion (mutex) A mutex is a simple lock that is shared between threads, used to protect critical regions of code or shared data structures. mutex m; mutex.lock() mutex.unlock() A mutex is often called a lock: the terms are mostly interchangeable When a thread attempts to lock a mutex: Currently unlocked: the thread takes the lock, and continues executing Currently locked: the thread blocks until the lock is released by the current lock- holder, at which point it attempts to take the lock again (and could compete with other waiting threads). Only the current lock-holder is allowed to unlock a mutex Deadlock can occur when threads form a circular wait on mutexes (e.g. dining philosophers) Places we've seen an operating system use mutexes for us: All file system operation (what if two programs try to write at the same time? create the same file?) Process table (what if two programs call fork() at the same time?) 3 lock_guard<mutex> The lock_guard<mutex> is very simple: it obtains the lock in its constructor, and releases the lock in its destructor.
    [Show full text]
  • Semaphores Semaphores (Basic) Semaphore General Vs. Binary
    Concurrent Programming (RIO) 20.1.2012 Lesson 6 Synchronization with HW support • Disable interrupts – Good for short time wait, not good for long time wait – Not good for multiprocessors Semaphores • Interrupts are disabled only in the processor used • Test-and-set instruction (etc) Ch 6 [BenA 06] – Good for short time wait, not good for long time wait – Nor so good in single processor system • May reserve CPU, which is needed by the process holding the lock – Waiting is usually “busy wait” in a loop Semaphores • Good for mutex, not so good for general synchronization – E.g., “wait until process P34 has reached point X” Producer-Consumer Problem – No support for long time wait (in suspended state) Semaphores in C--, Java, • Barrier wait in HW in some multicore architectures – Stop execution until all cores reached barrier_waitinstruction Linux, Minix – No busy wait, because execution pipeline just stops – Not to be confused with barrier_wait thread operation 20.1.2012 Copyright Teemu Kerola 2012 1 20.1.2012 Copyright Teemu Kerola 2012 2 Semaphores (Basic) Semaphore semaphore S public create initial value integer value semafori public P(S) S.value private S.V Edsger W. Dijkstra V(S) http://en.wikipedia.org/wiki/THE_operating_system public private S.list S.L • Dijkstra, 1965, THE operating system queue of waiting processes • Protected variable, abstract data type (object) • P(S) WAIT(S), Down(S) – Allows for concurrency solutions if used properly – If value > 0, deduct 1 and proceed • Atomic operations – o/w, wait suspended in list (queue?) until released – Create (SemaName, InitValue) – P, down, wait, take, pend, • V(S) SIGNAL(S), Up(S) passeren, proberen, try, prolaad, try to decrease – If someone in queue, release one (first?) of them – V, up, signal, release, post, – o/w, increase value by one vrijgeven, verlagen, verhoog, increase 20.1.2012 Copyright Teemu Kerola 2012 3 20.1.2012 Copyright Teemu Kerola 2012 4 General vs.
    [Show full text]
  • CSC 553 Operating Systems Multiple Processes
    CSC 553 Operating Systems Lecture 4 - Concurrency: Mutual Exclusion and Synchronization Multiple Processes • Operating System design is concerned with the management of processes and threads: • Multiprogramming • Multiprocessing • Distributed Processing Concurrency Arises in Three Different Contexts: • Multiple Applications – invented to allow processing time to be shared among active applications • Structured Applications – extension of modular design and structured programming • Operating System Structure – OS themselves implemented as a set of processes or threads Key Terms Related to Concurrency Principles of Concurrency • Interleaving and overlapping • can be viewed as examples of concurrent processing • both present the same problems • Uniprocessor – the relative speed of execution of processes cannot be predicted • depends on activities of other processes • the way the OS handles interrupts • scheduling policies of the OS Difficulties of Concurrency • Sharing of global resources • Difficult for the OS to manage the allocation of resources optimally • Difficult to locate programming errors as results are not deterministic and reproducible Race Condition • Occurs when multiple processes or threads read and write data items • The final result depends on the order of execution – the “loser” of the race is the process that updates last and will determine the final value of the variable Operating System Concerns • Design and management issues raised by the existence of concurrency: • The OS must: – be able to keep track of various processes
    [Show full text]
  • Lesson-9: P and V SEMAPHORES
    Inter-Process Communication and Synchronization of Processes, Threads and Tasks: Lesson-9: P and V SEMAPHORES Chapter-9 L9: "Embedded Systems - Architecture, Programming and Design", 2015 Raj Kamal, Publs.: McGraw-Hill Education 1 1. P and V SEMAPHORES Chapter-9 L9: "Embedded Systems - Architecture, Programming and Design", 2015 Raj Kamal, Publs.: McGraw-Hill Education 2 P and V semaphores • An efficient synchronisation mechanism • POSIX 1003.1.b, an IEEE standard. • POSIX─ for portable OS interfaces in Unix. • P and V semaphore ─ represents an integer in place of binary or unsigned integers Chapter-9 L9: "Embedded Systems - Architecture, Programming and Design", 2015 Raj Kamal, Publs.: McGraw-Hill Education 3 P and V semaphore Variables • The semaphore, apart from initialization, is accessed only through two standard atomic operations─ P and V • P (for wait operation)─ derived from a Dutch word ‘Proberen’, which means 'to test'. • V (for signal passing operation)─ derived from the word 'Verhogen' which means 'to increment'. Chapter-9 L9: "Embedded Systems - Architecture, Programming and Design", 2015 Raj Kamal, Publs.: McGraw-Hill Education 4 P and V Functions for Semaphore P semaphore function signals that the task requires a resource and if not available waits for it. V semaphore function signals which the task passes to the OS that the resource is now free for the other users. Chapter-9 L9: "Embedded Systems - Architecture, Programming and Design", 2015 Raj Kamal, Publs.: McGraw-Hill Education 5 P Function─ P (&Sem1) 1. /* Decrease the semaphore variable*/ sem_1 = sem_1 1; 2. /* If sem_1 is less than 0, send a message to OS by calling a function waitCallToOS.
    [Show full text]
  • Shared Memory Programming: Threads, Semaphores, and Monitors
    Shared Memory Programming: Threads, Semaphores, and Monitors CPS343 Parallel and High Performance Computing Spring 2020 CPS343 (Parallel and HPC) Shared Memory Programming: Threads, Semaphores, and MonitorsSpring 2020 1 / 47 Outline 1 Processes The Notion and Importance of Processes Process Creation and Termination Inter-process Communication and Coordination 2 Threads Need for Light Weight Processes Differences between Threads and Processes Implementing Threads 3 Mutual Exclusion and Semaphores Critical Sections Monitors CPS343 (Parallel and HPC) Shared Memory Programming: Threads, Semaphores, and MonitorsSpring 2020 2 / 47 Outline 1 Processes The Notion and Importance of Processes Process Creation and Termination Inter-process Communication and Coordination 2 Threads Need for Light Weight Processes Differences between Threads and Processes Implementing Threads 3 Mutual Exclusion and Semaphores Critical Sections Monitors CPS343 (Parallel and HPC) Shared Memory Programming: Threads, Semaphores, and MonitorsSpring 2020 3 / 47 What is a process? A process is a program in execution. At any given time, the status of a process includes: The code that it is executing (e.g. its text). Its data: The values of its static variables. The contents of its stack { which contains its local variables and procedure call/return history. The contents of the various CPU registers { particularly the program counter, which indicates what instruction the process is to execute next. Its state { is it currently able to continue execution, or must further execution wait until some event occurs (e.g. the completion of an IO operation it has requested)? CPS343 (Parallel and HPC) Shared Memory Programming: Threads, Semaphores, and MonitorsSpring 2020 4 / 47 What is a process? The chief task of an operating system is to manage a set of processes.
    [Show full text]
  • Software Transactional Memory with Interactions 3
    Software Transactional Memory with Interactions⋆ Extended Version Marino Miculan1 and Marco Peressotti2 1 University of Udine [email protected] 2 University of Southern Denmark [email protected] Abstract Software Transactional memory (STM) is an emerging ab- straction for concurrent programming alternative to lock-based synchron- izations. Most STM models admit only isolated transactions, which are not adequate in multithreaded programming where transactions need to interact via shared data before committing. To overcome this limitation, in this paper we present Open Transactional Memory (OTM), a pro- gramming abstraction supporting safe, data-driven interactions between composable memory transactions. This is achieved by relaxing isolation between transactions, still ensuring atomicity. This model allows for loosely-coupled interactions since transaction merging is driven only by accesses to shared data, with no need to specify participants beforehand. 1 Introduction Modern multicore architectures have emphasized the importance of abstractions supporting correct and scalable multi-threaded programming. In this model, threads can collaborate by interacting on shared data structures, such as tables, message queues, buffers, etc., whose access must be regulated to avoid inconsist- encies. Traditional lock-based mechanisms (like semaphores and monitors) are notoriously difficult and error-prone, as they easily lead to deadlocks, race con- ditions and priority inversions; moreover, they are not composable and hinder parallelism, thus reducing efficiency and scalability. Transactional memory (TM) has emerged as a promising abstraction to replace locks [5, 20]. The basic idea is to mark blocks of code as atomic; then, execution of each block will appear either as if it was executed sequentially and instantaneously at some unique point in time, or, if aborted, as if it did not execute at all.
    [Show full text]
  • Low Contention Semaphores and Ready Lists
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Purdue E-Pubs Purdue University Purdue e-Pubs Department of Computer Science Technical Reports Department of Computer Science 1980 Low Contention Semaphores and Ready Lists Peter J. Denning T. Don Dennis Jeffrey Brumfield Report Number: 80-332 Denning, Peter J.; Dennis, T. Don; and Brumfield, Jeffrey, "Low Contention Semaphores and Ready Lists" (1980). Department of Computer Science Technical Reports. Paper 261. https://docs.lib.purdue.edu/cstech/261 This document has been made available through Purdue e-Pubs, a service of the Purdue University Libraries. Please contact [email protected] for additional information. LOW CONTENTION SEMAPHORES AND READY LISTS Peter J. Denning T. Don Dennis Jeffrey Brumfield Computer Sciences Department Purdue University W. Lafayette, IN 47907 CSD-TR-332 February 1980 Revised June 1980 Abstract. A method for reducing sema­ phore and ready list contention in mul­ tiprocessor operating systems is described. Its correctness is esta­ blished. Its performance is compared with conventional implementations. A method of implementing the ready list with a ring network is proposed and evaluated. This work was supported in part by NSF Grant MCS78­ 01729 at Purdue University. June 18, 1980 - 2 - THE PROBLEM Modern operating systems implement semaphores for synchron- izing multiple concurrent processes. Unless the primitive opera- tions for starting, stopping, and scheduling processes and for manipulating semaphores are well supported by the hardware, con- text switching and interprocess signaling can be major overheads [1]. To avoid these overheads, many operating systems use fast, but unreliable ad hoc methods for synchronizing processes.
    [Show full text]
  • Semaphores (Dijkstra 1965)
    Semaphores (Dijkstra 1965) n Semaphores have a non-negative integer value, and support two operations: n semaphore->P(): an atomic operation that waits for semaphore Semaphores & Monitors to become positive, then decrements it by 1 n semaphore->V(): an atomic operation that increments semaphore by 1, waking up a waiting P, if any. n Semaphores are like integers except: Arvind Krishnamurthy (1) non-negative values; Spring 2004 (2) only allow P&V --- can’t read/write value except to set it initially; (3) operations must be atomic: -- two P’s that occur together can’t decrement the value below zero. -- thread going to sleep in P won’t miss wakeup from V, even if they both happen at about the same time. Implementing semaphores Using interrupts P means “test” (proberen in Dutch) V means “increment” (verhogen in Dutch) class Semaphore { int value = 0; } n Binary semaphores: Semaphore::P() { n Like a lock; can only have value 0 or 1 (unlike the previous Disable interrupts; Semaphore::V() { “counting semaphore” which can be any non-negative integers) while (value == 0) { Disable interrupts; Enable interrupts; value++; Disable interrupts; Enable interrupts; } } n How to implement semaphores? Standard tricks: value = value - 1; Enable interrupts; n Can be built using interrupts disable/enable } n Or using test-and-set n Use a queue to prevent unnecessary busy-waiting n Question: Can we build semaphores using just locks? Using test&set How to use semaphores n Binary semaphores can be used for mutual exclusion: class Semaphore { int value = 0; initial value of 1; P() is called before the critical section; and V() is called after the int guard = 0; } critical section.
    [Show full text]
  • Synchronization
    Synchronization CS 4410 Operating Systems [R. Agarwal, L. Alvisi, A. Bracy, M. George, E. Sirer, R. Van Renesse] • Foundations • Semaphores • Monitors & Condition Variables 2 Semaphores • Definition • Binary Semaphores • Counting Semaphores • Classic Sync. Problems (w/Semaphores) - Producer-Consumer (w/ a bounded buffer) - Readers/Writers Problem • Classic Mistakes with Semaphores 3 What is a Semaphore? [Dijkstra 1962] Dijkstra introduced in the THE Operating System Stateful: • a value (incremented/decremented atomically) • a queue • a lock Interface: • Init(starting value) • P (procure): decrement, “consume” or “start using” • V (vacate): increment, “produce” or “stop using” No operation to read the value! Dutch 4410: P = Probeer (‘Try'), V = Verhoog ('Increment', 'Increase by one') 4 Semantics of P and V P(): P() { • wait until value >0 while(n <= 0) ; • when so, decrement n -= 1; value by 1 } V(): V() { • increment value by 1 n += 1; } These are the semantics, but how can we make this efficient? (doesn’t this look like a spinlock?!?) 5 Implementation of P and V P(): P() { • block (sit on Q) til n > 0 while(n <= 0) • when so, decrement value by 1 ; n -= 1; V(): } • increment value by 1 • resume a thread waiting on Q V() { (if any) n += 1; } Okay this looks efficient, but how is this safe? 6 Implementation of P and V P() { P(): acquire(&guard); • block (sit on Q) til n > 0 while(n <= 0) { waiting.enq(self); • when so, decrement value by 1 release(&guard); sleep(); acquire(&guard); V(): } • increment value by 1 n -= 1; release(&guard);
    [Show full text]
  • Parallel Programming Models III (Pdf)
    Shared Memory Programming Models III Stefan Lang Interdisciplinary Center for Scientific Computing (IWR) University of Heidelberg INF 368, Room 532 D-69120 Heidelberg phone: 06221/54-8264 email: [email protected] WS 15/16 Stefan Lang (IWR) Simulation on High-Performance Computers WS15/16 1/36 Shared Memory Programming Models III Communication by shared memory Semaphore rep. Reader-Writer problem PThreads Active Objects Stefan Lang (IWR) Simulation on High-Performance Computers WS15/16 2/36 Semaphore A semaphore is an abstraction of a synchronisation variable, that enables the elegant solution of multiple of synchronisation problems Up-to-now all programs have used active waiting. This is very inefficient under quasi-parallel processing of multiple processes on one processor (multitasking). The semaphore enables to switch processes into an idle state. We understand a semaphore as abstract data type: Data structure with operations, that fulfill particular properties: A semaphore S has a non-negative integer value value(S), that is assigned during creation of the Semaphore with the value init. For a semaphore S two operations P(S) and V(S) are defined with: P(S) decrements the value of S by one if value(S) > 0, otherwise the process blocks as long as another process executes a Voperation on S. V(S) frees another process from a Poperation if one is waiting (are several waiting one is selected), otherwise the value of S is incremented by one. Voperations never block! Stefan Lang (IWR) Simulation on High-Performance Computers WS15/16 3/36 Readers/Writers Problem ReadersLeser WritersSchreiber DatabaseDatenbank Two classes of processes, readers and writers, access a common database.
    [Show full text]
  • Thread and Semaphore Examples
    CS107 Handout 23 Spring 2008 May 5, 2008 Thread and Semaphore Examples Handout prose by Julie Zelenski, examples written by Nick Parlante and Julie. Semaphores Since all threads run in the same address space, they all have access to the same data and variables. If two threads simultaneously attempt to update a global counter variable, it is possible for their operations to interleave in such way that the global state is not correctly modified. Although such a case may only arise only one time out of thousands, a concurrent program needs to coordinate the activities of multiple threads using something more reliable that just depending on the fact that such interference is rare. The semaphore is designed for just this purpose. A semaphore is somewhat like an integer variable, but is special in that its operations (increment and decrement) are guaranteed to be atomic—you cannot be halfway through incrementing the semaphore and be interrupted and waylaid by another thread trying to do the same thing. That means you can increment and decrement the semaphore from multiple threads without interference. By convention, when a semaphore is zero it is "locked" or "in use". Otherwise, positive values indicate that the semaphore is available. A semaphore will never have a negative value. Semaphores are also specifically designed to support an efficient waiting mechanism. If a thread can’t proceed until some change occurs, it is undesirable for that thread to be looping and repeatedly checking the state until it changes. In this case semaphore can be used to represent the right of a thread to proceed.
    [Show full text]