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