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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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;

Endread = proc (m:crt); m.readercount := m.readercount – 1; if m.readercount = 0 then condition signal(m.writers) end; end endread; Startwrite = … wait(m.writers) Endwrite =

Weakness of monitor construct: –Problem of associating the monitor with the resource it synchronizes => impaired modularity undermines correctness Solution in CLU: –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]; Analysis monitordatabase

First_come_first_serve –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

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

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

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) resourcemonitor Protected resource

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

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

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

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)

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

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

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

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 processType operation Path controller

Contd.. Syntax: –path 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 : –Sequencing: path open; read; close end –Selection: path read + write end fair ordering = (FCFS)

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

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”

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