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 = …<check for readers or writers>
wait(m.writers)Endwrite = <give priority to readers>
• 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];
Analysis
monitor database
• 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
• 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)
resource monitor
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: dataCrowd $join (s.readers_crowd) then d = data_base $read
(s.db, k);endreturn (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 process Type operation
Path controller
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)
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