1 / 29

Today’s Agenda

Today’s Agenda. Midterm: Nov 3 or 10 Finish Message Passing Race Analysis. Race Analysis. Introduction The Lockset Algorithm Message Race Detection. Race Conditions.

dane
Download Presentation

Today’s Agenda

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. Today’s Agenda • Midterm: Nov 3 or 10 • Finish Message Passing • Race Analysis Advanced Topics in Software Engineering 1

  2. Race Analysis • Introduction • The Lockset Algorithm • Message Race Detection Advanced Topics in Software Engineering 2

  3. Race Conditions • Many factors, such as unpredictable process scheduling and variations in message latencies, can contribute to the non-deterministic behavior of concurrent programs. • These factors can be informally referred to as raceconditions or just races. The activity of identifying races is referred to as race analysis. Advanced Topics in Software Engineering 3

  4. General & Data Races • There are two different types of races that capture different kinds of bugs. • General races cause nondeterministic execution and are failures in programs intended to be deterministic. • Data races cause non-atomic execution of critical sections and are failures in programs that access and update shared data in critical sections. Advanced Topics in Software Engineering 4

  5. Examples • Process 1 • /* deposit */ • amount = read_amount (); • P (mutex); • balance = balance + amount; • interest = interest + rate * balance; • V (mutex); • Process 2 • /* withdraw */ • amount = read_amount (); • P (mutex); • if (balance < amount) • printf (“NSF”); • else • balance = balance – amount; • interest = interest + rate * balance; • V (mutex); Process 1 /* deposit */ amount = read_amount (); P (mutex); balance = balance + amount; interest = interest + rate * balance; V (mutex); Process 2 /* withdraw */ amount = read_amount (); if (balance < amount) printf (“NSF”); else balance = balance – amount; interest = interest + rate * balance; Advanced Topics in Software Engineering 5

  6. Race Analysis • Introduction • The Lockset Algorithm • Message Race Detection Advanced Topics in Software Engineering 6

  7. Locking Discipline • A locking discipline is a programming policy that ensures the absence of data races. • For example, a simple locking discipline is to require that every variable shared between threads is protected by a mutual exclusion lock. • The lockset algorithm is to ensure that all shared-memory accesses follow the simple locking discipline. Advanced Topics in Software Engineering 7

  8. The Algorithm (1) • For each shared variable v, the algorithm maintains the set C(v) of candidate locks as follows: • When a variable is initialized, C(v) contains all possible locks; • When a variable is accessed, C(v) is replaced with the intersection of C(v) and the set of locks held by the current thread. • If C(v) becomes empty, it signals that there is no lock that consistently protects v. (Otherwise, there is at least one lock that remains in C(v).) Advanced Topics in Software Engineering 8

  9. The Algorithm (2) for each shared variable v, initialize CandidateLocks(v) to the set of all locks On each read or write access to v by thread T CandidateLocks(v) = CandidateLocks(v)  LocksHeld (T) if (CandidateLocks(v) =={}) issue a warning. Advanced Topics in Software Engineering 9

  10. Example (1) • Thread 1LocksHeld(Thread1) CandidateLocks(s) • { } { mutex1, mutex2} • mutex1.lock(); { mutex1 } { mutex1, mutex2 } • s = s + 1; { mutex1 } { mutex1, mutex2} • mutex1.unlock(); { } { mutex1 } • mutex2.lock(); { mutex2 } { mutex1 } • s = s + 2; { mutex2 } { } • mutex2.unlock(); { } { } Advanced Topics in Software Engineering 10

  11. Example (2) LocksHeld CandidateLocks {} {mutex1, mutex2} mutex1.lock {mutex1, mutex2} {mutex1} read s {mutex1} {mutex1} write s {mutex1} {mutex1} mutex1.unlock {} {mutex1} mutex2.lock {mutex2} {mutex1} read s {mutex2} {} Advanced Topics in Software Engineering 11

  12. False Alarms • The simple locking discipline is strict, in the sense that some common programming practices violate this discipline and are still free from data races: • Initialization: Shared variables are frequently initialized without a lock. • Read-sharedData: Some shared variables are written during initialization and are read-only thereafter. Advanced Topics in Software Engineering 12

  13. Initialization • There is no need for a thread to lock out others if no other can possibly hold a reference to the data being accessed. • To avoid false alarms caused by unlocked writes during initialization, we delay the refinement of a location’s candidate set until after it has been initialized. • However, there is no easy way of knowing initialization is complete. Any solution? Advanced Topics in Software Engineering 13

  14. Read-shared Data • Since simultaneous reads of a shared variable by multiple threads are not races, there is also no need to protect variable if it is read-only. • To avoid false alarms caused by unlocked read-sharing for such data, we report races only after an initialized variable has become write-shared by more than one thread. Advanced Topics in Software Engineering 14

  15. exclusive shared virgin State Transitions rd/wr, first thread wr wr, new thread shared- modified rd, new thread rd wr Advanced Topics in Software Engineering 15

  16. Race Analysis • Introduction • The Lockset Algorithm • Message Race Detection Advanced Topics in Software Engineering 16

  17. Asynchronous vs. Synchronous • In an asynchronous message-passing program, each process uses non-blockingsend and blockingreceive operations to send and receive messages. • This is in contrast with synchronous message-passing, where blockingsend and blockingreceive operations are used. Advanced Topics in Software Engineering 17

  18. Communication Scheme (1) • A communicationscheme may impose certain restrictions on the relationship between the order in which messages are sent and the order in which messages are received. • The behavior of an asynchronous message-passing program depends on its underlying communicationscheme. Advanced Topics in Software Engineering 18

  19. Communication Scheme (2) • The fullyasynchronous scheme allows that messages are received out of order. • The FIFO scheme requires that messages exchanged between any two processes be received in the same order as they are sent. • The causal scheme requires that all the messages are received in the same order as they are sent. Advanced Topics in Software Engineering 19

  20. SR-sequence • An execution of an asynchronous message-passing program exercises a sequence of send and receive events, or an SR-sequence. • Formally, an SR-sequence is defined as a triple (S, R, Y), where S is a set of send events, R a set of receive events, and Y a set of synchronizations. Advanced Topics in Software Engineering 20

  21. P1 P2 P3 P1 P2 s1 s1 r1 s2 r2 r1 s3 r2 r3 Example Causal  FIFO  Fully Asyn. P1 P2 P3 s1 s5 s2 r5 s2 r2 s4 s3 r1 r4 r3 Causal FIFO Fully Asyn. Advanced Topics in Software Engineering 21

  22. Message Race (1) • Informally, there exists a messagerace between two send events if the messages sent by the two events may be received by the same receive event. • Given an SR-sequence, we can perform race analysis, and determine, for each receive event, the set of send events that may send messages to this receive event. Advanced Topics in Software Engineering 22

  23. Message Race (2) • Message race shall be independent from program implementation. P1 P2 P3 s1 s2 r1 r2 Advanced Topics in Software Engineering 23

  24. P1 P1 P2 P2 P3 P3 s1 s1 r1 r1 s2 s2 r2 r2 s3 s3 r3 r3 Message Race (3) Message race depends on the underlying communication scheme. Causal FIFO or Asyn. Advanced Topics in Software Engineering 24

  25. Message Race Detection (1) • Let P be an asynchronous message-passing program consisting of processes P1, P2, ..., and Pn. Let Q be the SR-sequence exercised by one execution of P. • Let r be a receive event in Q. Assume that r receives the message sent by a send event s in Q. A send event s’ is in the race set, race(r), of r if the message sent by s’ can be received by r in another execution. • Race analysis of Qisto determine race(r) for every receive event r in Q. Advanced Topics in Software Engineering 25

  26. Message Race Detection (2) • Assume that the fully asynchronous communication scheme is used. Let r be a receive event of Pi. A send event s of Pj is in race(r) if the following two conditions are met: • the message sent by s is destined to Pi. • r does not happen before s • if s is received by r’, then r must happen before r’. Advanced Topics in Software Engineering 26

  27. Message Race Detection (3) • Assume that the FIFO communication scheme is used. Let r be a receive event of Pi. A send event s of Pj is in race(r) if the following three conditions are met: • the message sent by s is destined to Pi. • r does not happen before s • if s is received by r’, then r must happen before r’. • there does not exist another send event s’ of Pj such that s’ happens before s and s’ satisfies the above two conditions or is synchronized with r. Advanced Topics in Software Engineering 27

  28. Message Race Detection (4) • Assume that the Causal communication scheme is used. Let r be a receive event of Pi. A send event s of Pj is in race(r) if the following three conditions are met: • the message sent by s is destined to Pi. • r does not happen before s • if s is received by r’, then r must happen before r’. • there does not exist another send event s’ of any process such that s’ happens before s and s’ satisfies the above two conditions or is synchronized with r. Advanced Topics in Software Engineering 28

  29. Message Race Detection (5) P1 P2 P3 P4 s1 s2 r1 s3 s4 r2 r3 s5 r5 r4 s6 r6 s7 r7 s8 r8 Advanced Topics in Software Engineering 29

More Related