Liveness: The Readers / Writers Problem

Liveness: The Readers / Writers Problem Admin stuff: Minute paper for concurrency revision lecture Please take one, fill out in 1st 5min & return to box at front by end of lecture Labs week 4 review: event logging: monitor (BufferSem.java) vs threads (RunBufferSem.java), use of invariants, rate of failure Assignment 1: who/what decides which server is calls a ticket? Overview: the problem, formulating the model the model: readers & writers, model lock, safety, progress the implementation: monitor, safety action priority: modelling, analysis & implementation (these slides including graphics are a modified version of the slides from Ch7 of Magee & Kramer: Concurrency) COMP2310 Lecture 13: Liveness: Readers/Writers 2014 1

The Readers and Writers Problem Light blue indicates database access A shared database is accessed by two kinds of processes: readers execute transactions that examine the database: multiple readers may concurrently access the database writers both examine and update the database: A writer must have exclusive access COMP2310 Lecture 13: Liveness: Readers/Writers 2014 2

events or actions of interest? Formulating the Readers/Writers Model Ö Ð Ê ÕÙ Ö ÏÖ Ø Ö Ð ÏÖ Ø ÕÙ Ö Ê readers, writers & the RW Lock identify desired properties: RW Safe, RW Progress define each process and its interactions (structure) COMP2310 Lecture 13: Liveness: Readers/Writers 2014 3

\ Ü Ñ Ò }º { ÕÙ Ö ÏÖ Ø > ÑÓ Ý > Ö Ð ÏÖ Ø > ÏÊÁÌ Ê µ ÏÊÁÌ Ê Readers/Writers Model: Reader & Writer Ø ÓÒ Ø ÕÙ Ö Ê Ö Ð Ê ÕÙ Ö ÏÖ Ø { Ö Ð ÏÖ Ø } > > > Ø ÓÒ \ ÑÓ Ý}º { alphabet extension ensures that the other access actions cannot occur freely for any prefixed instance of the process (as before) i.e. when combined with the readers/writer lock monitor, which can talk to either instance action hiding is used as Ü Ñ Ò actions ÑÓ Ý and are not relevant for access synchronization COMP2310 Lecture 13: Liveness: Readers/Writers 2014 4

Readers/Writers Model: RW Lock Ð ¼ ÓÒ Ø ÌÖÙ ½ ÓÒ Ø ÓÓÐ Ð ºº ÌÖÙ Ö Ò ÆÖ ¾»» Å Ü ÑÙÑ Ö Ö ÓÒ Ø ÆÛÖ Ø ¾»» Å Ü ÑÙÑ ÛÖ Ø Ö ÓÒ Ø Ï Ä Ç Ã ÊÏ ¼ Ð Ê Ö Ö ¼ºº ÆÖ ÛÖ Ø Ò ÓÓÐ ÊÏ Û Ò ÛÖ Ø Ò µ > ÊÏ Ö Ö ½ ÛÖ Ø Ò ÕÙ Ö Ê Ö Ð Ê ÊÏ Ö Ö ½ ÛÖ Ø Ò > Û Ò Ö Ö ¼ ²² ÛÖ Ø Ò µ > ÊÏ Ö Ö ÌÖÙ ÕÙ Ö ÏÖ Ø Ö Ð ÏÖ Ø ÊÏ Ö Ö Ð > µº The lock maintains a count of the number of readers, and a Boolean for the writers. Q1: what monitor invariant (relationship Ö Ö between and ÛÖ Ø Ò ) should we have here? ÛÖ Ø Ò ²² Ö Ö ¼ (a) ÛÖ Ø Ò ²² Ö Ö ¼ (b) (c) ÛÖ Ø Ò Ö Ö ¼ (d) ÛÖ Ø Ò Ö Ö ¼ COMP2310 Lecture 13: Liveness: Readers/Writers 2014 5

µ ½ºº ÆÖ Ê ÁÆ µ ÏÊÁÌÁÆ Readers/Writers Model: Safety Property ÔÖÓÔ ÖØÝ Ë Ê Ï ÕÙ Ö Ê > Ê ÁÆ ½ ÕÙ Ö ÏÖ Ø ÏÊÁÌÁÆ > ÕÙ Ö Ê > Ê ÁÆ ½ Û Ò >½µ Ö Ð Ê Ê ÁÆ ½ > Û Ò ½µ Ö Ð Ê Ë Ê Ï > Ö Ð ÏÖ Ø > Ë Ê Ï µº We can check whether ÊÏ ÄÇ Ã satisfies the safety property Ê ÏÊÁÌ ÄÇ Ã Ê Ï Ä Ç Ã Ë Ê Ï µº Q2 (T/F): Adding a safety É property to a process È È, Assume É that itself cannot deadlock. ɵ, can cause deadlock. COMP2310 Lecture 13: Liveness: Readers/Writers 2014 6

Readers/Writers Model An ÊÊÇÊ occurs if a reader or writer is badly behaved (Ö Ð before ÕÙ Ö ) or more than two readers. We now compose the Ê ÏÊÁÌ ÄÇ Ã with the Ê Ê and ÏÊÁÌ Ê processes according to our structure (check safety and LTS before/after minimization) Ê ÊË ÏÊÁÌ ÊË Ö Ö ½ºº ÆÖ Ê Ê ÛÖ Ø Ö ½ºº ÆÛÖ Ø ÏÊÁÌ Ê { Ö Ö ½ºº ÆÖ ÛÖ Ø Ö ½ºº ÆÛÖ Ø } Ê ÏÊÁÌ ÄÇ Ã µº COMP2310 Lecture 13: Liveness: Readers/Writers 2014 7

ÏÊÁÌ ½ºº ÆÛÖ Ø ÛÖ Ø Ö º ÕÙ Ö ÏÖ Ø ÔÖÓ Ö Ê ½ºº ÆÛÖ Ø Ö Ö º ÕÙ Ö Ê ÔÖÓ Ö Readers/Writers: Progress ÏÊÁÌ : eventually one of the writers will ÕÙ Ö ÏÖ Ø Ê : eventually one of the readers will ÕÙ Ö Ê what adverse conditions should we impose via action priority? we lower the priority of the release actions for both readers and writers ÊÏ ÈÊÇ Ê ËË Ê ÊË ÏÊÁÌ ÊË >> Ö Ö ½ºº ÆÖ º Ö Ð Ê { ÛÖ Ø Ö ½ºº ÆÖ º Ö Ð ÏÖ Ø }º Progress Analysis? LTS? Q3 (T/F): (in general) adding action priority can cause deadlock. COMP2310 Lecture 13: Liveness: Readers/Writers 2014 8

Readers/Writers: Progress Progress violation: WRITE.1 WRITE.2 Trace to terminal set of states: reader.2.acquireread Cycle in terminal set: reader.1.acquireread reader.1.releaseread writer starvation: the number of readers never drops to zero The applet also demonstrates this. COMP2310 Lecture 13: Liveness: Readers/Writers 2014 9

Readers/Writers Implementation: Monitors we first define an interface ReadWrite which all implementations must satisfy: ÚÓ ÕÙ Ö Ê µ Ø ÖÓÛ ÁÒØ ÖÖÙÔØ Ü ÔØ ÓÒ ÚÓ Ö Ð Ê µ ÚÓ ÕÙ Ö ÏÖ Ø µ Ø ÖÓÛ ÁÒØ ÖÖÙÔØ Ü ÔØ ÓÒ ÚÓ Ö Ð ÏÖ Ø µ } now, the safe readers/writers lock: ÒØ Ö Ö ¼ ÔÖ Ú Ø ÓÓÐ Ò ÛÖ Ø Ò Ð ÔÖ Ú Ø ÝÒ ÖÓÒ Þ ÚÓ ÕÙ Ö Ê µ Ø ÖÓÛ ÁÒØ ººº Ü ÔØ ÓÒ { } ÛÖ Ø Ò µ Û Ø µ»» Û Ò ÛÖ Ø Ò µ Û Ð Ö Ö»» ÕÙ Ö Ê >ÊÏ Ö Ö ½ ÛÖ Ø Ò ÝÒ ÖÓÒ Þ ÚÓ Ö Ð Ê µ { } Ö Ö ¼µ ÒÓØ Ý ÐÐ µ»» ÓÒÐÝ Ò ØÓ ÒÓØ Ý ½ ÛÖ Ø Ö ÝÒ ÖÓÒ Þ ÚÓ ÕÙ Ö ÏÖ Ø µ Ø ÖÓÛ ÁÒØ ººº Ü ÔØ ÓÒ { Ö Ö > ¼ ÛÖ Ø Ò µ Û Ø µ Û Ð Ö Ö»» Ö Ð Ê >ÊÏ Ö Ö ½ ÛÖ Ø Ò ØÖÙ»» Û Ò Ö Ö ¼ ²² ÛÖ Ø Ò µ ÛÖ Ø Ò»» ÕÙ Ö ÏÖ Ø >ÊÏ Ö Ö ÌÖÙ } ÝÒ ÖÓÒ Þ ÚÓ Ö Ð ÏÖ Ø µ { л» Ö Ð ÏÖ Ø >ÊÏ Ö Ö Ð ÛÖ Ø Ò µ } ÒÓØ Ý ÐÐ COMP2310 Lecture 13: Liveness: Readers/Writers 2014 10

> ÏÊÁÌ Ê µ Ö Ð ÏÖ Ø Ø ÓÒ \ { ÑÓ Ý}º Ï Ä Ç Ã ÊÏ ¼ Ð ¼ Ê Ö Ö ¼ºº ÆÖ ÛÖ Ø Ò ÓÓÐ Û Ø Ò Ï ¼ºº ÆÛÖ Ø ÊÏ Revised Readers/Writers Model: Writer Priority writers can still get starved if number of readers never drops to 0 strategy: block readers if there are writers waiting introduce ÕÙ Ö ÏÖ Ø a action to inform the system (monitor) of this Ö ÕÙ ØÏÖ Ø > ÕÙ Ö ÏÖ Ø > ÑÓ Ý > ÏÊÁÌ Ê modify the monitor to count waiting writers and, if so, block readers Û Ò ÛÖ Ø Ò ²² Û Ø Ò Ï ¼µ > ÊÏ Ö Ö ½ ÛÖ Ø Ò Û Ø Ò Ï ÕÙ Ö Ê Ö Ð Ê ÊÏ Ö Ö ½ ÛÖ Ø Ò Û Ø Ò Ï > Û Ò Ö Ö ¼ ²² ÛÖ Ø Ò µ > ÊÏ Ö Ö ÌÖÙ Û Ø Ò Ï ½ ÕÙ Ö ÏÖ Ø Ö Ð ÏÖ Ø ÊÏ Ö Ö Ð Û Ø Ò Ï > Ö ÕÙ ØÏÖ Ø ÊÏ Ö Ö ÛÖ Ø Ò Û Ø Ò Ï ½ > µº COMP2310 Lecture 13: Liveness: Readers/Writers 2014 11

Writer Priority Readers/Writers: Analysis ÔÖÓÔ ÖØÝ ÊÏ Ë : No deadlocks/errors ÔÖÓ Ö Ê and ÔÖÓ Ö ÏÊÁÌ : Progress violation: READ.1 READ.2 Trace to terminal set of states: writer.2.requestwrite Actions in terminal set: writer[1..2].{acquirewrite, releasewrite, requestwrite} we now get reader starvation, if there is always a writer waiting! in practice, this may be satisfactory as is usually more read access than write, and readers generally want the most up to date information COMP2310 Lecture 13: Liveness: Readers/Writers 2014 12

Readers/Writers Implementation: Priority ReadWritePriority.java implements the ÊÏ ÄÇ Ã with priority: ÒØ Ö Ö ¼ ÔÖ Ú Ø ÓÓÐ Ò ÛÖ Ø Ò Ð ÔÖ Ú Ø ÒØ Û Ø Ò Ï ¼ ÔÖ Ú Ø ÝÒ ÖÓÒ Þ ÚÓ ÕÙ Ö Ê µ Ø ÖÓÛ ÁÒØ ººº Ü ÔØ ÓÒ { ÛÖ Ø Ò Û Ø Ò Ï > ¼µ Û Ø µ Û Ð } Ö Ö ÝÒ ÖÓÒ Þ ÚÓ Ö Ð Ê µ { } Ö Ö Ö Ö ¼µ ÒÓØ Ý ÐÐ µ»» Ñ Ý Ð Ó Ö Ö Û Ø Ò ÝÒ ÖÓÒ Þ ÚÓ ÕÙ Ö ÏÖ Ø µ Ø ÖÓÛ ÁÒØ ººº Ü ÔØ ÓÒ { Û Ø Ò Ï Ö Ö > ¼ ÛÖ Ø Ò µ Û Ø µ Û Ð Û Ø Ò Ï } ÛÖ Ø Ò ØÖÙ ÝÒ ÖÓÒ Þ ÚÓ Ö Ð ÏÖ Ø µ { Ð ÛÖ Ø Ò µ } ÒÓØ Ý ÐÐ both Ê and ÏÊÁÌ properties can be satisfied by introducing a ØÙÖÒ variable COMP2310 Lecture 13: Liveness: Readers/Writers 2014 13

Summary: Safety and Liveness concepts: properties: must be true for every possible execution aim: property satisfaction safety: nothing bad ever happens liveness: something good eventually happens models: safety: no reachable ÊÊÇÊ / ËÌÇÈ state. We can compose safety properties at appropriate stages. liveness: an action is eventually executed scheduling via fair choice and action priority We must apply progress checks on the final target system model. practice: threads and monitors COMP2310 Lecture 13: Liveness: Readers/Writers 2014 14