Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Chapter 7 Synchronization and Multiprocessors. 2 Contents u Introduction u Synchronization in traditional UNIX kernel u Multiprocessor system u Multiprocessor.

Similar presentations


Presentation on theme: "1 Chapter 7 Synchronization and Multiprocessors. 2 Contents u Introduction u Synchronization in traditional UNIX kernel u Multiprocessor system u Multiprocessor."— Presentation transcript:

1 1 Chapter 7 Synchronization and Multiprocessors

2 2 Contents u Introduction u Synchronization in traditional UNIX kernel u Multiprocessor system u Multiprocessor Synchronization issues u Spin locks u Condition variables u Read-write locks u Reference counts

3 3 Introduction u Compute-intensive u Multiprocessors also provides reliability. u MTBF u Fault-tolerant u Recover from the failure u Performance scales linearly? u Other components u Synchronization u Extra functionality u Three major changes u Synchronization u Parallelization u Scheduling policy

4 4 7.2 Synchronization in traditional UNIX u The UNIX kernel is reentrant. u The UNIX kernel is nonpreemptive.

5 5 Interrupt Masking u The kernel can be interrupted. u The interrupts can be preemptive. u The kernel thread keep a current ipl to mask the interrupts with the ipls lower than it.

6 6 Sleep and wakeup u Flags for shared resources u Locked u Wanted u Before accessing, check locked, yes, blocking and set wanted u After accessing, check wanted, yes, awaken all the waiting

7 7 Limitations u Performance problem u Mapping resources to sleep queues u Sleep channel(the resource address) and sleep queue(hash map) u >1 may map to the same channel u The number of hash queue is much smaller than the number of different sleep channels. u Too much time for awakening u Separate sleep queue for each resource u Too many spaces

8 8

9 9 Per resource sleep queues

10 10 Alternatives u Separate sleep queue for each resource or event – latency is optimized but requires large memory overhead u Solaris turnstiles –more predictable real-time behaviour with minimal overhead; u It is desirable to have more sophisticated sharing protocol to allow multiple readers but exclusive writing access

11 Multiprocessor Systems u 3 important characteristics of MP u Memory model, hardware support, & software architecture u Memory Model u UMA (Uniform Memory Access) u NUMA (Non-Uniform Memory Access) u NORMA (NO-Remote Memory Access)

12 12 Memory models

13 13 Memory models

14 14

15 15 NORMA

16 16 Synchronization Support u Locking a resource for exclusive use u Read the flag u If the flag is 0, then set it to 1 u Return true if the lock was obtained, else false. u Atomic test-and-set u test&set->access ->reset u Load-linked & store-conditioned u loadl(M,R)-> access(R)->storec(M,R)

17 17

18 18 Implement test-&-set by load- link & store-conditional u void test&set(int s)//primitive u { while (s!=0); u s=1; u } u void test&set(int s) //primitive u { register r; u while (loadl(r,s)& r!=0); u r=1; u storec(r,s); u }

19 19 Software Architecture u Three types of multiprocessor systems u Master-slave u One for kernel, the others for user u One for I/O, the others for computing u Functionally asymmetric multiprocessors u Different CPU is for different types of applications u Symmetric multiprocessing u All CPUs are peer-to-peer, share a kernel code, run the user program.

20 Multiprocessor Synchronization issues u Need to protect all the data shared u Two kernel threads may access the data simultaneously u Locked flag is not enough u Test&set u Impossible to block an interrupt u Other CPU running the handler may corrupt a data being accessed.

21 21 The lost wakeup problem Wait()

22 22 The Thundering Herd Problem u Uni-processor u When releasing the resource, wake up all the threads waiting for it. u Multiprocessor u All waked up, all the threads will run on different CPUs.What a mess! u It is the Thundering Herd Problem.

23 Semaphores void initsem(semaphore *sem, int val){ *sem = val; } void P(semaphore *sem){ *sem-=1; while(*sem<0) sleep; } void V(semaphore *sem){ *sem+=1; if(*sem>=0) wakeup a thread blocked on sem; } boolean_t CP(semaphore *sem){ if(*sem>0) { *sem-=1; return TRUE; } else return FALSE; } Semaphore operations

24 24 Mutual Exclusion ;/*initialization*/ semaphore sem initsem(&sem,1); /*on each use*/ P(&sem); Use resource; V(&sem);

25 25 Event-Wait semaphore event; initsem(&event,0); P(&event); Doing something; V(&event); If (event occurs) V(&event);

26 26 Countable resources semaphore counter; Initsem(& counter,resourceCount); P(&counter); Use resource; V(&counter);

27 27 Drawbacks of semaphores u It needs the hardware to support its atomicity. u Context switching is time-costing, so blocking is expensive for a short-term using resource. u May hide the details for blocking, e.g., buffer cache.

28 28 Convoys u A convoy is a situation when there is frequent contention on a semaphore.

29 29 Spin Locks u Also called simple lock or a simple mutex void spin_lock(spinlock_t *s) { while (test_and_set (s) !=0); } void spin_unlock(spinlock_t *s) { *s=0; }

30 30 Another version u For saving time of locking the bus void spin_lock(spinlock_t *s) { while (test_and_set (s) !=0) while (*s!=0); } void spin_unlock(spinlock_t *s) { *s=0; }

31 31 Using spin-locks u The difference between UNIP and MP. u Spin-lock is not expensive. u Ideal for locking data structures that need to be accessed briefly (removing item from a list) spin_lock_t list; spin_lock( &list); item->forw->back = item->back; item->back ->forw = item ->forw; spin_unlock(&list);

32 32 Condition Variables u v – condition variable, m – mutex lock predicate x==y; Thread A a: lock_mutex(&m); b:while (x!=y) c:cond_wait(&v, &m);/*atomically releases*/ /* the mutex and blocks*/ /*when unblocked by the cond_signal, it reacquires the mutex*/ d: /*do something with x and y*/ e: unlock_mutex(&m);

33 33 Condition Variables u Thread B f: lock_mutex(&m); g:x++; h: cond_signal(&v); i: unlock_mutex(&m);

34 34 Condition Variables u Associated with a predicate. Request queue Client 1 Client 2 Client m … Server 1 Server 2 Server n … Empty? A message queue is the shared data The predicate is that the queue be nonempty.

35 35 implementation u Atomic operation to test the predicate. struct condition{ proc *next; proc *prev; spinlock_t listlock; }

36 36 wait() void wait(condition *c, spinlock_t *s) { spin_lock(&c->listlock); add self to the linked list; spin_unlock(&c->listlock); spin_unlock(s); swtch(); spin_lock(s); return; }

37 37 void do_signal() void do_signal(condition*c){ spin_lock(&c->listlock); remove one thread from linked list, if it is nonempty; spin_unlock(&c->listlock); if a thread was removed from the list, make it runnable; return; }

38 38 void do_broadcast() void do_broadcast(condition*c){ spin_lock(&c->listlock); while (linked list is nonempty){ remove one thread from linked list, make it runnable; } spin_unlock(&c->listlock); }

39 39 Accessing conditional variables condition c; spinlock_t s; mesageQueue msq; server() {spin_lock(&s); if (msq.empty()) wait(&c,&s); get message; spin_unlock(&s); do_signal( &c ); } client() {spin_lock(&s); if (msq.full()) wait(&c,&s); put message; spin_unlock(&s); do_signal( &c ); }

40 40 Events u Combines a done flag, the spinlock protecting it and a condition variable Operations – awaitDone, setDone or testDone u Blocking locks combines locked flag on the resource and the sleep queue; operations – lock() and unlock()

41 Read-Write locks u Support one-writer & many readers u lockShared() // Reader u unlockShared() // Reader u lockExclusive() // Writer u unlockExclusive() // Writer u upgrade() // from shared to exclusive u downgrade() //from exclusive to shared

42 42 Design consideration u Avoid needless wake up u Reader release u only the last to wake up a single writer u Writer release: u prefer writer u Reader starvation u wake up all the readers u Writer starvation u lockShared() block if there is any writer waiting //new readers

43 43 Implementation struct rwlock{ int nActive; // number of readers, -1 means a writer is active int nPendingReads; int nPendingWrites; spinlock_t sl; condition canRead; condition canWrite; };

44 44 un/lockShared void unlockShared(struct rwlock *r) { spin_lock(&r->sl); r->nActive --; if (r-> nActive ==0){ spin_unlock (&r->sl); do_signal(&r->canWrite); } else spin_unlock(&r->sl); } void lockShared(struct rwlock *r) { spin_lock(&r->sl); r->nPendingReads++; if (r->nPendingWrites>0) wait(&r->canRead, &r->sl); while(r->nActive <0) wait(&r->canRead, &r->sl); r->nActive++; r->nPendingReads--; spin_unlock(&r->sl); }

45 45 un/lockExclusive void unlockExclusive(struct rwlock *r) { boolean_t wakeReaders; spin_lock(&r->sl); r->nActive =0; wakeReaders = (r->PendingReads!=0); spin_unlock(&r->sl); if (wakeReaders){ do_broadcast(&r->canRead); else do_signal(&r->canWrite); } void lockExclusive(struct rwlock *r) { spin_lock(&r->sl); r->nPendingWrites++; while(r->nActive) wait(&r->canWrite, &r->sl); r->nPendingWrites--; r->nActive =-1; spin_unlock(&r->sl); }

46 46 Up/downgrade() void downgrade(struct rwlock *r) { boolean_t wakeReaders; spin_lock(&r->sl); r->nActive =1; wakeReaders = (r->PendingReads!=0) spin_unlock(&r->sl); if (wakeReaders){ do_broadcast(&r->canRead); } void upgrade(struct rwlock *r) { spin_lock(&r->sl); if (r->nActive ==1) r->nActive =-1; else{ r->nPendingWrites++; r->nActive--; while (r->nActive) wait(&r->canWrite, &r->sl); r->nPendingWrites--; r->nActive =-1; } spin_unlock(&r->sl); }

47 47 Using R/W locks rwlock l; T1() { lockShared(&l); reading; upgrade(&l) writing; downgrade(&l) unlockShared(&l); } T2() { lockExclusive(&l); writing; downgrade(&l); reading; upgrade(&l); unlockExclusive(&l); }

48 48 Reference Counts u A number kept with an object to show how many threads have pointers to it. u To keep the threads pointing to it can access it. u When creating, set to one. u When one thread gets a pointer to it, the number increments. u When the thread release it, the kernel will decrement it. u When the count is decreased to 0, the kernel will de-allocate it.

49 49 Deadlock avoidance u Hierarchical locking – imposes an order on related locks and requires that all threads take locks in the same order, e.g. thread must lock condition variable before locking the linked list; u Stochastic locking – when order violation may occur try_lock() is used instead of lock(). If the lock cannot be acquired because it is allocated already it returns a failure instead of blocking.

50 50 Recursive locks u Lock, which is owned by a thread is acquired by a lower level routine which is called by the thread to perform some operation on resource locked by the thread. Without recursion there would be deadlock.

51 51 To block or spin u If the thread already holds a simple mutex it is not allowed to block; u If the thread tries to acquire another simple mutex, it will busy wait; u If the thread tries to acquire a complex lock, it will release the mutex it already holds u One solution – a hint (advisory or mandatory, set by the owner of the lock) in a lock suggesting whether the contending thread should spin or lock, u Alternative – adaptive lock of Solaris – threads T1 and T2 - T1 tries to get a lock held by T2, - if T2 is active then T1 busy wait, - if T2 is blocked, T1 blocks as well,

52 52 Others issues u What to lock – data, predicates, invariants or operations; u Granularity - from a single lock for the whole kernel – to separate lock for each data variable u Duration – it is best to hold the lock for as short a time as possible, to minimize contention on it – sometimes it makes sense to keep it longer without an intermediate release

53 53 Case study - SVR4.2/MP u Basic locks, u Read-write locks, u Sleep locks, u Synchronization variables.

54 54 Linux Kernel Concurrency Mechanisms u Includes all the mechanisms found in UNIX u Atomic operations execute without interruption and without interference

55 55 Linux Atomic Operations

56 56 Linux Atomic Operations

57 57 Linux Kernel Concurrency Mechanisms u Spinlocks u Used for protecting a critical section

58 58

59 59 Linux Kernel Concurrency Mechanisms


Download ppt "1 Chapter 7 Synchronization and Multiprocessors. 2 Contents u Introduction u Synchronization in traditional UNIX kernel u Multiprocessor system u Multiprocessor."

Similar presentations


Ads by Google