Advanced Synchronization Constructs

1. Advanced Synchronization Constructs Related Work: Monitors: An Operating System Structuring, C.A.R Hoare (developing on Brinch Hansen’s concepts) Synchronization in actor systems, Russell Atkinson, Carl Hewitt

2. Basic Motivation • High level language constructs • Supporting parallel programming • Modular programming techniques • We need synchronization mechanisms • Issue: Evaluation of Mechanisms

3. Criteria (and consequently Evaluation Techniques) • Expressive power • Ease of use • Modularity • Modifiability • Correctness

4. Modularity • Synchronization part of definition of shared resource - not stated at the time/place of use of the resource • Synchronization separable from definition of shared resource

5. Categorization of synchronization problems • Def: Sychronization scheme = set of constraints • Exclusion: if condition then process A is excluded from the resource • Sequencing: if condition then process A has priority over process B • Priority constraints • Concurrency constraints

6. Categorization of information available to the synchronizer • Procedures requested • E.g. read or write • Time of request • Orderings • Synchronization state • Processes using procedures • Local state of resource • History of information

7. Definition of power of synchronization mechanism • Express exclusion + priority • Express either in terms of information available to synchronizer

8. Examples • Bounded buffer problem • Readers – Writers problem • One slot buffer problem • Disk scheduler problem • Alarm clock problem

9. Expressive power (E.P) • Def: • Straightforward methods for expressing priority and exclusion • Ability to express these constraints in terms of information available

10. Techniques for determination of E.P • Sample synchronization problems • Features of mechanisms allowing it to deal with constraints and information types • E.g. queues • Not used: translation between mechanisms • E.g: • P/V • Wait / Signal

11. Ease of use • Def: • Ability to easily construct implementations of couple of synchronization schemes made up of many constraints • Independant implementations of constraints • Text independence of constraints by comparison of solutions to similar synchronization problems • Example: • Compare readers writers problem with common exclusion constraint but differing priorities

12. Modifiability • Def: small change in synchronization spec => small change in implementation • Depends on constraint independence property

13. Correctness • Def: • Mechanism features that aid in or impede the production of correct programs • Deadlock possibilities (hierarchy of synchronization)

14. Monitors Monitor_name = monitor is op1,…,opn; Rep = record […local data …] Op1 = proc() Op1 = proc() End monitor_name • Ops are defined as mutually exclusive • Ops are needed to get access to a shared resource • The monitor object may contain the resource object

15. Sample Monitors • Bounded buffer (resource contained in monitor) • Exclusion constraints described using (resource state) • Use of FCFS queues for priority (implicit) • Readers writers problem (resource outside monitor) • Four operations • One to be used before and one after each resource access • Readers priority • Local variables (synch state) • Busy • Reader count • Use of (ref_type)

16. Contd.. • Readers priority monitor: Readers_priority = monitor is create, startread, endread, startwrite, endwrite; Rep= record [readercount = int, busy = boolean, readers, writers: condition]; Create = … Startread = proc (m:crt); if m.busy then condition wait(m.readers) end; m.readercount := m.readercount + 1; condition signal(m.reader) end startread;

17. Endread = proc (m:crt); m.readercount := m.readercount – 1; if m.readercount = 0 then condition signal(m.writers) end; end endread; Startwrite = … <check for readers or writers> wait(m.writers) Endwrite = <give priority to readers>

18. Analysis • Weakness of monitor construct: • Problem of associating the monitor with the resource it synchronizes => impaired modularity undermines correctness • Solution in CLU: <study> • Build a protected database abstraction that contains both the monitor and the synchronizer • Protected_data_base = cluster is create, read, write; • Rep = record[m:readers_priority, d:data_base]; monitor database

19. First_come_first_serve <study> • Differences to previous solution: • Queuing scheme • Readers+writers on a single queue => Ordered by request time • Problem: • Exclusion constraint for writer need not be satisfied when signal is done on the single queue • Reason for problem: • Cannot examine state / condition of head of queue without de-queuing it • Solution: • have de-queued writers wait a second queue if necessary + adjust signaling

20. No-ordering : writers_exclude_others • Difficult in monitors due to use of queues, which imply orderings / priorities • History information : one_slot buffer = [alternate insert / remove] • Monitors do not have explicit sequencing operations / Constructs • Keep local data in monitor recording history • More easily done using path expressions • Constraints based on arguments: • Alarmclock monitor • Difficult again – de-queuing problem

21. Conclusions - Expressive power - Monitors • Information representation: • (req type) (req time) • Maintained by queues • (arguments) • Maintained by priority queuing • (synchronization state) (history) (local state) • Explicit as local variables • Representation of sequencing + exclusion: • Explicit signals potentially conflicting and cumbersome • However good efficiency

22. Modularity • General scheme: • Issues : • Monitoring consistency in resources • Possibility of deadlocks if nested monitor calls occur • Separation prevents deadlock in most cases • Exception : monitors performing resource calls (state info) resource monitor Protected resource

23. Ease of use and modifiability • Recall: independence of constraints • Correctness • Monitor mechanism : • Issue: explicit use of signals • Deadlock possibility in cases of hierarchical structuring • Problem with wait / signal • Signal condition => queue use • Buf: condition true ≠> queue use – must be programmed

24. Serializers • Differences • Monitors • Serializers • Incorporate a means for invoking resource operations outside the control of the synchronizer • Replace signal constructs with automatic signalling • Def: Serializer – • Module with operations which are mutually exclusive • Encapsulates resource => protected resource

25. Serializers - Details • Operations : • Enter – gain possession of serializer • (wait ≈) Enqueue – release possession • (signal ≈) Dequeue – regain possession • For concurrency purposes • Join_crowd – release possession and enter resource • Leave_crowd – leave resource, re-enter serializer • Exit – release serializer

26. Contd.. • Enqueue (queue) until condition • Join (crowd) then body end • Leave_crowd is executed automatically • Data types: • Queues • No wait /signal • Enqueue/dequeue specify conditions • Automatic restart of process when it becomes queue head • Condition not checked until process reaches head of queue • Crowds • Unordered collections of processes • Handle (synchronization state)

27. FCFS_Readers_Writers FCFS = serializer is read, write, create; Rep = record [ waiting_q : queue, readers_crowd : crowd, writers_crowd : crowd, db : data_base]; Read = proc(s:crt, k:key) returns (data); queue $enqueue (s.waiting_q) until crowd $empty (s.writers_crowd); D: data Crowd $join (s.readers_crowd) then d = data_base $read (s.db, k); end return (d); end read; … end FCFS

28. Expressive Power -Serializers • Due to automatic signaling users need not explicitly specify orderings if conditions of multiple queues can/ do become true • But: not clear how serializer handles this problem • Deadlock problems persist: • E.g. if the serializer needs to know about resourcestat by invocation of a resource op then a deadlock is possible • (history) requires local variables so does resourcestat unless resource ops are used

29. Modularity • Improvement ovr monitors in • Separating resource implementation from synchronization • Hiearchical structures supported • Ease of use and modifiability • Correctness • Conclusions • Performance of crowds and automatic signaling

30. Path Expressions • Resource access gained by use of its operations => synchronization of resource can be defined as {allowable orderings} of operations • Scheme – path is associated with a resource => no control over which process executes the operation • Implementation User process Type operation Path controller

31. Contd.. • Syntax: • path <ordering expression> end • Semantics: • This sequence can be repeated any number of times • Several paths in one module = > an operation must be consistent with all paths • Unnamed operation => no restrictions apply • Operations in a path are not concurrent, unless specifid explicitly • <ordering expression>: • Sequencing: • path open; read; close end • Selection: • path read + write end fair ordering = (FCFS)

32. Contd.. • Concurrency: • path {read} + write end • All reads complete => this portion of path is complete • path {read}; write end • Atleast one read must occur between writes • path {write;read} end • Any number of writes and reads may be executing at once,but a read can only start after a write concurrent reads

33. Expressive power • Writers_exclude_others • Include “path {read} + write end” in the database module • Straightforward implementation of (exclusion) constraint • Use of (req type) • Nondeterminate specification = > requires “fair” selections by path controller • Monitors more complex due to use of queues • Dealing with non determinacy to implement determinate schemes: FCFS i.e. this path says nothing of “order of service to readers”

34. Expressive power Conclusions • Easy – simple exclusion constraints • Hard – priority constraints • Res. State • Arguments • Nice – non procedural approach to synchronization