1 / 23

Locks, channels, deadlock freedom, progress

This text discusses the concepts of locks, channels, and deadlocks in the context of ensuring progress and freedom. It explores the locking order, object life cycle, and reordering of locks. It also covers channels, progress problems, and credit accounting. The text provides examples and syntax for using locks and channels effectively.

hani
Download Presentation

Locks, channels, deadlock freedom, progress

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. Locks, channels, deadlock freedom, progress K. Rustan M. Leino Peter Müller IFIP WG 2.3 meeting 49 10 June 2009 Boston, MA

  2. Chalice object life cycle (abridged) share thread local shared,available • Locks are objects, objects are locks new release shared,locked acquire

  3. Locking order in Chalice • Every lock has an associated locking level • Locks have to be acquired in ascending order, which avoids deadlocks

  4. Locking order details • Locking order is a dense semi-lattice(Mu, <<, , ) • << is the strict version of << • The locking level of an object o is stored in a mutable ghost field o.mu • Accessing o.mu requires appropriate permissions

  5. Example method M(o: C)requiresrd(o.mu) maxlock << o.mu …{acquire o …release o} (lHeld  l.mu)

  6. Semantics (defined by pseudo code) share thread local shared,available o := new C ≡ … o.mu :=  … share o between L and H ≡assertCanWrite(o,mu)  o.mu = ;assert L << H;havocμ; assume L << μ << H;o.mu := μ;ExhaleMonitorInv(o); acquire o ≡ assertCanRead(o,mu);assertmaxlock << o.mu;Held := Held  {o};InhaleMonitorInv(o); release o ≡ assert o  Held;ExhaleMonitorInv(o);Held := Held – {o}; new release shared,locked acquire

  7. Lock reordering reorder o between L and H ≡ assertCanWrite(o,mu)  o.mu ≠ ; assert L << H; assert o  Held; havocμ; assume L << μ << H; o.mu := μ; method M(o: C)requiresrd(o.mu) maxlock << o.mu …{acquire o …release o} (lHeld  l.mu)

  8. Threads • forktk := o.M() • jointk

  9. Join deadlock Thread 0: • forktk := o.M()acquire pjointkrelease p Thread 1: • method M() …{acquire p …release p}

  10. Avoiding join deadlocks • Tokens record the initial maxlock of the new thread • forktk := o.M() ≡tk.forkMaxlock := maxlock; … • jointk ≡assertmaxlock<<tk.forkMaxlock; …

  11. Example corrected Thread 0: • forktk := o.M()acquire pjointkrelease p Thread 1: • method M()requiresrd(p.mu) maxlock << p.mu{acquire p …release p}

  12. Channels • channelName(signature) wherepredicate • Example:channel Ch(t: T) whereacc(t.x)  0 ≤ t.x < 100 • Channels have unbounded slack • that is: sends are non-blocking • ch := new Ch • sendch(E) ≡ Exhale Where(ch); • receive x := ch ≡ Inhale Where(ch);

  13. Progress problems Thread 0: • receive x := ch • acquire oreceive x := ch Thread 1: • /* No send. Ever. */ • acquire osendch(E) or:

  14. Credits • Channels have associated credits • cf. memory locations have associated permissions • receive requires a credit • send produces a credit • Specification syntax: credit(ch, n)where n is an integer, denotes n credits for channel ch • If omitted, n defaults to 1 • Negative credits are debits

  15. Encoding of credits • Introduce a per-activation-record credits counter C : channel  int • cf. per-activation-record permissions mask P in Peter’s talk • Inhalecredit(ch,n) ≡ C[ch] := C[ch] + n • Exhalecredit(ch,n) ≡ C[ch] := C[ch] – n

  16. Credit accounting sell where clause,obtain 1 credit • ch := new Ch ≡ … C[ch] := 0; … • sendch(E) ≡Inhalecredit(ch,1); Exhale Where(ch); • receive x := E ≡assert C[ch] > 0;Inhale Where(ch); Exhalecredit(ch,1); pay 1 credit,receive where clause

  17. Ensuring progress • Associate a locking level also with every channel ch, recorded in a field ch.mu • ch := new Ch between L and H ≡ … • receive x := ch ≡ assertCanRead(ch,mu) maxlock << ch.mu;… // as before • sendch(E) ≡ assertCanRead(ch,mu); ?… // as before • reorder – not yet worked out

  18. Going into debt • maxlock ≡(lHeld  l.mu)  (ch | C[ch] < 0  ch.mu) • Inhalecredit(ch,n) ≡ Exhalecredit(ch,-n) • Exhalecredit(ch,n) ≡ assert C[ch] – n < 0 ≤ C[ch] maxlock << ch.mu; C[ch] := C[ch] – n;

  19. Credit-leak checking • At the end of every activation record: assert(ch 0 ≤ C[ch]);

  20. Producer / Consumer example class Cell { varval: int; … } channel Ch(x: Cell) where x ≠ nullacc(x.val)  0 ≤ x.val credit(this) class Program { method Main() …method Producer(ch: Ch) …method Consumer(ch: Ch) …}

  21. P/C: Main method Main() { varch := new Ch fork tk0 := Producer(ch) fork tk1 := Consumer(ch) join tk0 join tk1 }

  22. P/C: Producer method Producer(ch: Ch)requiresrd(ch.mu)ensurescredit(ch, 1) { while (…)invariantrd(ch.mu){var x := …sendch(x)} sendch(null)} or: requiresrd(ch.mu) requirescredit(ch, -1) ensurestrue

  23. P/C: Consumer method Consumer(ch: Ch)requiresrd(ch.mu) maxlock << ch.murequirescredit(ch)ensuresrd(ch.mu) {receive x := chwhile (x ≠ null)invariant x ≠ nullcredit(ch){ …receive x := ch } }

More Related