CDS-03 Communication & Synchronization · 2020. 9. 1. · Towards synchronization process P1;...

266

Co

mm

un

icat

ion

& S

ynch

ron

izat

ion

© 2

020

Uw

e R

. Zim

mer

, The

Aus

tral

ian

Nat

iona

l Uni

vers

ity

page

266

of 7

58 (c

hapt

er 3

: “C

omm

unic

atio

n &

Syn

chro

niza

tion”

up

to p

age

369)

Bas

ic s

ynch

roni

zati

on

by S

emap

hore

sB

asic

defi

nit

ion

(Dijk

stra

196

8)

Ass

um

ing

the

follo

win

g th

ree

con

dit

ion

s o

n a

sh

ared

mem

ory

cel

l bet

wee

n p

roce

sses

:

• a

set o

f pro

cess

es a

gree

on

a v

aria

ble

S o

per

atin

g as

a

fl ag

to in

dic

ate

syn

chro

niz

atio

n c

on

dit

ion

s

• an

ato

mic

op

erat

ion

P o

n S

— fo

r ‘p

asse

ren

’ (D

utc

h fo

r ‘p

ass’

):

P(S)

: [as

soo

n as

S >

0 t

hen

S :=

S -

1]

this

is a

po

ten

tial

ly d

elay

ing

op

erat

ion

aka:

‘Wai

t’, ‘S

usp

end

_Un

til_

Tru

e’, ‘

sem

_wai

t’, …

• an

ato

mic

op

erat

ion

V o

n S

— fo

r ‘vr

ygev

en’ (

Du

tch

for ‘

to r

elea

se’):

V(S

): [S

:=

S +

1]

aka

‘Sig

nal

’, ‘S

et-T

rue’

, ‘se

m_p

ost

’, …

th

en th

e va

riab

le S

is c

alle

d a

Sem

apho

re.

262

Co

mm

un

icat

ion

& S

ynch

ron

izat

ion

© 2

020

Uw

e R

. Zim

mer

, The

Aus

tral

ian

Nat

iona

l Uni

vers

ity

page

262

of 7

58 (c

hapt

er 3

: “C

omm

unic

atio

n &

Syn

chro

niza

tion”

up

to p

age

369)

Tow

ards

syn

chro

niza

tion

Co

ndit

ion

sync

hro

niza

tio

n by

fl ag

s

Ass

um

pti

on

: wo

rd-a

cces

s at

om

icit

y:

i.e. a

ssig

nin

g tw

o v

alu

es (n

ot w

ider

than

the

size

of a

‘wo

rd’)

to a

n a

lign

ed m

emo

ry c

ell c

on

curr

entl

y:

x :=

0

|

x :

= 50

0

will

res

ult

in e

ith

er x =

0 o

r x =

500

– a

nd

no

oth

er v

alu

e is

eve

r o

bse

rvab

le

258

Co

mm

un

icat

ion

& S

ynch

ron

izat

ion

© 2

020

Uw

e R

. Zim

mer

, The

Aus

tral

ian

Nat

iona

l Uni

vers

ity

page

258

of 7

58 (c

hapt

er 3

: “C

omm

unic

atio

n &

Syn

chro

niza

tion”

up

to p

age

369)

Sani

ty c

heck

i++;

{in

one

thre

ad}

if i

> n

{i=

0;}

{in

anot

her

thre

ad}

Do

we

need

to

? –

real

ly?

int

i; {

decl

are

glob

ally

to

mult

iple

thr

eads

}

Wh

at's

the

wo

rst t

hat

can

hap

pen

?

254

3C

omm

unic

atio

n &

Syn

chro

niza

tion

Uw

e R

. Zim

mer

- T

he A

ustr

alia

n N

atio

nal U

nive

rsity

Syst

ems,

Net

wo

rks

& C

on

curr

ency

202

0

267

Co

mm

un

icat

ion

& S

ynch

ron

izat

ion

© 2

020

Uw

e R

. Zim

mer

, The

Aus

tral

ian

Nat

iona

l Uni

vers

ity

page

267

of 7

58 (c

hapt

er 3

: “C

omm

unic

atio

n &

Syn

chro

niza

tion”

up

to p

age

369)

Tow

ards

syn

chro

niza

tion

proc

ess

P1;

st

atem

ent

X;

wa

it (

sync

)

st

atem

ent

Y;en

d P1

;

proc

ess

P2;

st

atem

ent

A;

si

gnal

(sy

nc);

st

atem

ent

B;en

d P2

;

Co

ndit

ion

sync

hro

niza

tio

n by

sem

apho

res

var

sync

: s

emap

hore

:=

0;

Seq

uen

ce o

f op

erat

ion

s: A

B<

; X

AY

<;

6@

; ,

XY

B;

6@

263

Co

mm

un

icat

ion

& S

ynch

ron

izat

ion

© 2

020

Uw

e R

. Zim

mer

, The

Aus

tral

ian

Nat

iona

l Uni

vers

ity

page

263

of 7

58 (c

hapt

er 3

: “C

omm

unic

atio

n &

Syn

chro

niza

tion”

up

to p

age

369)

Tow

ards

syn

chro

niza

tion

Co

ndit

ion

sync

hro

niza

tio

n by

fl ag

s

Ass

um

ing

furt

her

that

ther

e is

a s

har

ed m

emo

ry a

rea

bet

wee

n tw

o p

roce

sses

:

• A

set

of p

roce

sses

agr

ee o

n a

(wo

rd-s

ize)

ato

mic

var

iab

le o

per

atin

g as

a fl

ag to

ind

icat

e sy

nch

ron

izat

ion

co

nd

itio

ns:

259

Co

mm

un

icat

ion

& S

ynch

ron

izat

ion

© 2

020

Uw

e R

. Zim

mer

, The

Aus

tral

ian

Nat

iona

l Uni

vers

ity

page

259

of 7

58 (c

hapt

er 3

: “C

omm

unic

atio

n &

Syn

chro

niza

tion”

up

to p

age

369)

Sani

ty c

heck

i++;

{in

one

thre

ad}

if i

> n

{i=

0;}

{in

anot

her

thre

ad}

Do

we

need

to

? –

real

ly?

int

i; {

decl

are

glob

ally

to

mult

iple

thr

eads

}

Han

dlin

g a

64-b

it in

tege

r o

n a

8- o

r 16

-bit

co

ntr

olle

r w

ill n

ot b

e at

om

ic

… y

et p

erh

aps

it is

an

8-b

it in

tege

r. U

nal

ign

ed m

anip

ula

tio

ns

on

the

mai

n m

emo

ry w

ill u

sual

ly n

ot b

e at

om

ic

… y

et p

erh

aps

it is

a a

lign

ed.

Bro

ken

do

wn

to a

load

-op

erat

e-st

ore

cyc

le, t

he

op

erat

ion

s w

ill u

sual

ly n

ot b

e at

om

ic

… y

et p

erh

aps

the

pro

cess

or s

up

plie

s at

om

ic o

per

atio

ns

for t

he

actu

al c

ase.

Man

y sc

hed

ule

rs in

terr

up

t th

read

s ir

resp

ecti

ve o

f sh

ared

dat

a o

per

atio

ns

… y

et p

erh

aps

this

sch

edu

ler i

s aw

are

of t

he

shar

ed d

ata.

Lo

cal c

ach

es m

igh

t no

t be

coh

eren

t

… y

et p

erh

aps

they

are

.

255

Co

mm

un

icat

ion

& S

ynch

ron

izat

ion

© 2

020

Uw

e R

. Zim

mer

, The

Aus

tral

ian

Nat

iona

l Uni

vers

ity

page

255

of 7

58 (c

hapt

er 3

: “C

omm

unic

atio

n &

Syn

chro

niza

tion”

up

to p

age

369)

Ref

eren

ces

for

this

cha

pter

[Ben

-Ari

06]

M. B

en-A

riPr

inci

ple

s o

f Co

ncu

rren

t an

d D

is-

trib

ute

d P

rogr

amm

ing

2006

, sec

on

d e

dit

ion

, Pre

nti

ce-

Hal

l, IS

BN

0-1

3-71

1821

-X

[ Bar

nes2

006 ]

Bar

nes

, Jo

hn

Pr

ogr

amm

ing

in A

da

2005

A

dd

iso

n-W

esle

y, P

ears

on

ed

uca

tio

n, I

SBN

-13

978

-0-3

21-3

4078

-8, H

arlo

w, E

ngl

and

, 200

6

[ Go

slin

g200

5 ] G

osl

ing,

Jam

es , J

oy,

B , S

teel

e,

Gu

y &

Bra

cha,

Gila

d

The

Java

™ L

angu

age

Spec

ifi ca

tio

n

- th

ird

ed

itio

n

2005

[Ad

aRM

2012

]A

da

Refe

ren

ce M

anu

al -

Lan

-gu

age

and

Sta

nd

ard

Lib

rari

es;

ISO

/IEC

865

2:20

1x (E

)

[Cha

pel

1.1

1.0

Lang

uage

Sp

ecifi

cati

on

Vers

ion

0.97

]se

e co

urs

e p

ages

or

http

://c

hap

el.c

ray.

com

/sp

ec/s

pec

-0.9

7.p

df r

elea

sed

on

2. A

pri

l 201

5

[ Sar

asw

at20

10 ]

Sara

swat

, Vija

y Re

po

rt o

n th

e Pr

ogr

amm

ing

Lan

guag

e X

10

Vers

ion

2.0

1 D

raft

— Ja

nu

ary

13, 2

010

268

Co

mm

un

icat

ion

& S

ynch

ron

izat

ion

© 2

020

Uw

e R

. Zim

mer

, The

Aus

tral

ian

Nat

iona

l Uni

vers

ity

page

268

of 7

58 (c

hapt

er 3

: “C

omm

unic

atio

n &

Syn

chro

niza

tion”

up

to p

age

369)

Tow

ards

syn

chro

niza

tion

proc

ess

P1;

st

atem

ent

X;

wa

it (

mute

x);

stat

emen

t Y;

si

gnal

(mu

tex)

;

st

atem

ent

Z;en

d P1

;

proc

ess

P2;

st

atem

ent

A;

wa

it (

mute

x);

stat

emen

t B;

si

gnal

(mu

tex)

;

st

atem

ent

C;en

d P2

;

Mut

ual e

xclu

sio

n by

sem

apho

res

var

mute

x :

sema

phor

e :=

1;

Seq

uen

ce o

f op

erat

ion

s:A

BC

<<

; XY

Z<

<;

,,

,X

ZA

BC

;6

@; ,

,,

AC

XY

Z;

6@;

BY

J;

6@

264

Co

mm

un

icat

ion

& S

ynch

ron

izat

ion

© 2

020

Uw

e R

. Zim

mer

, The

Aus

tral

ian

Nat

iona

l Uni

vers

ity

page

264

of 7

58 (c

hapt

er 3

: “C

omm

unic

atio

n &

Syn

chro

niza

tion”

up

to p

age

369)

Tow

ards

syn

chro

niza

tion

proc

ess

P1;

st

atem

ent

X;

re

peat

unt

il F

lag;

st

atem

ent

Y;en

d P1

;

proc

ess

P2;

st

atem

ent

A;

Fl

ag :

= tr

ue;

st

atem

ent

B;en

d P2

;

Co

ndit

ion

sync

hro

niza

tio

n by

fl ag

s

var

Flag

: b

oole

an :

= fa

lse;

Seq

uen

ce o

f op

erat

ion

s: A

B<

; X

AY

<;

6@

; ,

XY

B;

6@

260

Co

mm

un

icat

ion

& S

ynch

ron

izat

ion

© 2

020

Uw

e R

. Zim

mer

, The

Aus

tral

ian

Nat

iona

l Uni

vers

ity

page

260

of 7

58 (c

hapt

er 3

: “C

omm

unic

atio

n &

Syn

chro

niza

tion”

up

to p

age

369)

Sani

ty c

heck

i++;

{in

one

thre

ad}

if i

> n

{i=

0;}

{in

anot

her

thre

ad}

Do

we

need

to

? –

real

ly?

int

i; {

decl

are

glob

ally

to

mult

iple

thr

eads

}

Han

dlin

g a

64-b

it in

tege

r o

n a

8- o

r 16

-bit

co

ntr

olle

r w

ill n

ot b

e at

om

ic

… y

et p

erh

aps

it is

an

8-b

it in

tege

r. U

nal

ign

ed m

anip

ula

tio

ns

on

the

mai

n m

emo

ry w

ill u

sual

ly n

ot b

e at

om

ic

… y

et p

erh

aps

it is

a a

lign

ed.

Bro

ken

do

wn

to a

load

-op

erat

e-st

ore

cyc

le, t

he

op

erat

ion

s w

ill u

sual

ly n

ot b

e at

om

ic

… y

et p

erh

aps

the

pro

cess

or s

up

plie

s at

om

ic o

per

atio

ns

for t

he

actu

al c

ase.

Man

y sc

hed

ule

rs in

terr

up

t th

read

s ir

resp

ecti

ve o

f sh

ared

dat

a o

per

atio

ns

… y

et p

erh

aps

this

sch

edu

ler i

s aw

are

of t

he

shar

ed d

ata.

Lo

cal c

ach

es m

igh

t no

t be

coh

eren

t

… y

et p

erh

aps

they

are

.

s iii

cccc eeerrrrrrhrh

oad

-op

ll u

sual

ly n

oooootttttt

nssssssssss

ssss s inininininin

ptete

rru

pper

ruppp

rupppp

t th

rett

hre

tth

rethh

reh

reread

sad

si

ads

irad

ss irirr

pppre

srerere

spec

pees

pec

esp

espsp

ecpp

ececcti

ve o

ttive

oti

veo

tive

oti

veo

ivvevvveve

oeooo

f sh

arf s

har

fsfsh

fsh

fsh

arfs

ha

shshhhhar

harararr

ed d

ated

dat

edd

aed

dat

eeedd

ated

dat

edd

ddd

atd

atdd

ataaatatp

a o

per

ao

per

aao

per

ao

per

ao

per

ao

per

ao

paaa

op

op

op

ero

per

pee

atio

ns

atio

ns

atio

ns

atio

ns

atio

ns

atio

ns

atio

ns

atio

ns

atio

ns

aatatttio

ns

tio

ns

ion

sio

ns

oon

s

p…

yet

tper

hap

hhs

pppu

lati

on

s o

n th

e m

ain

mem

ory

will

usu

ally

no

t be

ato

mic

… y

et p

eaaaa

load

-op

erat

e-st

ore

cyc

le, t

he

op

erat

ion

s w

ill u

sual

ly n

o

… y

et p

erh

aps

the

pro

cess

or s

up

plie

sat

om

ic o

per

atio

ns

inte

rru

ptt

hre

ads

irre

spec

tif

hd

dt

Even

if a

ll as

sum

pti

on

s h

old

:

Ho

w to

exp

and

this

co

de?

256

Co

mm

un

icat

ion

& S

ynch

ron

izat

ion

© 2

020

Uw

e R

. Zim

mer

, The

Aus

tral

ian

Nat

iona

l Uni

vers

ity

page

256

of 7

58 (c

hapt

er 3

: “C

omm

unic

atio

n &

Syn

chro

niza

tion”

up

to p

age

369)

Ove

rvie

w

Sync

hro

niza

tio

n m

etho

ds

Shar

ed m

emo

ry b

ased

syn

chro

niz

atio

n•

Sem

aph

ore

s C

, PO

SIX

— D

ijkst

ra

• C

on

dit

ion

al c

riti

cal r

egio

ns

E

dis

on

(exp

erim

enta

l)

• M

on

ito

rs

Mo

du

la-1

, Mes

a —

Dijk

stra

, Ho

are,

…

• M

ute

xes

& c

on

dit

ion

al v

aria

ble

s P

OSI

X

• Sy

nch

ron

ized

met

ho

ds

Jav

a, C

#, …

• Pr

ote

cted

ob

ject

s A

da

• A

tom

ic b

lock

s C

hap

el, X

10

Mes

sage

bas

ed s

ynch

ron

izat

ion

• A

syn

chro

no

us

mes

sage

s e

.g. P

OSI

X, …

• Sy

nch

ron

ou

s m

essa

ges

e.g

. Ad

a, C

HIL

L, O

ccam

2, …

• R

emo

te in

voca

tio

n, r

emo

te p

roce

du

re c

all

e.g

. Ad

a, …

269

Co

mm

un

icat

ion

& S

ynch

ron

izat

ion

© 2

020

Uw

e R

. Zim

mer

, The

Aus

tral

ian

Nat

iona

l Uni

vers

ity

page

269

of 7

58 (c

hapt

er 3

: “C

omm

unic

atio

n &

Syn

chro

niza

tion”

up

to p

age

369)

Tow

ards

syn

chro

niza

tion

Sem

apho

res

in A

da

pack

age

Ada.

Sync

hron

ous_

Task

_Con

trol

is

ty

pe S

uspe

nsio

n_Ob

ject

is

limi

ted

priv

ate;

pr

oced

ure

Set_

True

(

S :

in o

ut S

uspe

nsio

n_Ob

ject

);

proc

edur

e Se

t_Fa

lse

(S

: in

out

Sus

pens

ion_

Obje

ct);

fu

ncti

on

Curr

ent_

Stat

e

(

S :

S

uspe

nsio

n_Ob

ject

) re

turn

Boo

lean

;

proc

edur

e Su

spen

d_Un

til_

True

(S

: in

out

Sus

pens

ion_

Obje

ct);

priv

ate

…

----

-- n

ot s

peci

fied

by

the

lang

uage

end

Ada.

Sync

hron

ous_

Task

_Con

trol

;

on

ly o

ne

task

can

be

blo

cked

at S

uspe

nd_U

ntil

_Tru

e!

(Pro

gram

_Err

or w

ill b

e ra

ised

wit

h a

sec

on

d ta

sk tr

yin

g to

su

spen

d it

self

)

no

qu

eues

! m

inim

al r

un

-tim

e o

verh

ead

Th

is is

"q

ueu

eles

s" a

nd

can

tran

slat

e

into

a s

ingl

e m

ach

ine

inst

ruct

ion

.

265

Co

mm

un

icat

ion

& S

ynch

ron

izat

ion

© 2

020

Uw

e R

. Zim

mer

, The

Aus

tral

ian

Nat

iona

l Uni

vers

ity

page

265

of 7

58 (c

hapt

er 3

: “C

omm

unic

atio

n &

Syn

chro

niza

tion”

up

to p

age

369)

Tow

ards

syn

chro

niza

tion

Co

ndit

ion

sync

hro

niza

tio

n by

fl ag

s

Ass

um

ing

furt

her

that

ther

e is

a s

har

ed m

emo

ry a

rea

bet

wee

n tw

o p

roce

sses

:

• A

set

of p

roce

sses

agr

ee o

n a

(wo

rd-s

ize)

ato

mic

var

iab

le o

per

atin

g as

a fl

ag to

ind

icat

e sy

nch

ron

izat

ion

co

nd

itio

ns:

Mem

ory

fl ag

met

ho

d is

ok

for

sim

ple

co

nd

itio

n s

ynch

ron

izat

ion

, bu

t …

… is

no

t su

itab

le fo

r ge

ner

al m

utu

al e

xclu

sio

n in

cri

tica

l sec

tio

ns!

… b

usy

-wai

tin

g is

req

uir

ed to

po

ll th

e sy

nch

ron

izat

ion

co

nd

itio

n!

Mo

re p

ow

erfu

l syn

chro

niz

atio

n o

per

atio

ns

are

req

uir

ed fo

r cr

itic

al s

ecti

on

s

261

Co

mm

un

icat

ion

& S

ynch

ron

izat

ion

© 2

020

Uw

e R

. Zim

mer

, The

Aus

tral

ian

Nat

iona

l Uni

vers

ity

page

261

of 7

58 (c

hapt

er 3

: “C

omm

unic

atio

n &

Syn

chro

niza

tion”

up

to p

age

369)

Sani

ty c

heck

i++;

{in

one

thre

ad}

if i

> n

{i=

0;}

{in

anot

her

thre

ad}

Do

we

need

to

? –

real

ly?

int

i; {

decl

are

glob

ally

to

mult

iple

thr

eads

}

Th

e ch

ance

s th

at s

uch

pro

gram

min

g er

rors

turn

ou

t are

usu

ally

sm

all a

nd

so

me

im-

plic

it b

y ch

ance

syn

chro

niz

atio

n in

the

rest

of t

he

syst

em m

igh

t pre

ven

t th

em a

t all.

(Man

y ef

fect

s st

emm

ing

fro

m a

syn

chro

no

us

mem

ory

acc

esse

s ar

e in

terp

rete

d

as (h

ard

war

e) ‘g

litch

es’,

sin

ce th

ey a

re u

sual

ly r

are,

yet

oft

en d

isas

tro

us.

) O

n a

ssem

ble

r le

vel o

n v

ery

sim

ple

CPU

arc

hit

ectu

res:

syn

chro

niz

atio

n b

y em

plo

yin

g kn

ow

led

ge a

bo

ut t

he

ato

mic

ity

of C

PU-o

per

atio

ns

and

inte

r-ru

pt s

tru

ctu

res

is n

ever

thel

ess

po

ssib

le a

nd

uti

lized

in p

ract

ice.

In a

nyt

hin

g h

igh

er th

an a

ssem

ble

r le

vel o

n s

ingl

e co

re, p

red

icta

ble

µ-c

on

tro

llers

:

Mea

sure

s fo

r sy

nch

ron

izat

ion

are

req

uir

ed!

257

Co

mm

un

icat

ion

& S

ynch

ron

izat

ion

© 2

020

Uw

e R

. Zim

mer

, The

Aus

tral

ian

Nat

iona

l Uni

vers

ity

page

257

of 7

58 (c

hapt

er 3

: “C

omm

unic

atio

n &

Syn

chro

niza

tion”

up

to p

age

369)

Mot

ivat

ion

Sid

e ef

fect

sO

per

atio

ns

hav

e si

de

effe

cts

wh

ich

are

vis

ible

…

eith

er …

loca

lly o

nly

(an

d p

rote

cted

by

run

tim

e-, o

s-, o

r h

ard

war

e-m

ech

anis

ms)

or

… o

utsi

de t

he c

urre

nt p

roce

ss

If s

ide

effe

cts

tran

scen

d th

e lo

cal p

roce

ss th

en a

ll fo

rms

of a

cces

s n

eed

to b

e sy

nch

ron

ized

.

282

Communication & Synchronization

© 2020 Uwe R. Zimmer, The Australian National University page 282 of 758 (chapter 3: “Communication & Synchronization” up to page 369)

Centralized synchronization

Monitors

monitor buffer;

export append, take;

var (* declare protected vars *)

procedure append (I : integer); …

procedure take (var I : integer); …begin (* initialisation *)end;

How to implement

conditional synchronization?

278



Distributed synchronization

Conditional Critical Regions

Basic idea:

• Critical regions are a set of associated code sections in different processes, which are guaranteed to be executed in mutual exclusion:

• Shared data structures are grouped in named regions and are tagged as being private resources.

• Processes are prohibited from entering a critical region, when another process is active in any associated critical region.

• Condition synchronisation is provided by guards:

• When a process wishes to enter a critical region it evaluates the guard (under mu-tual exclusion). If the guard evaluates to false, the process is suspended / delayed.

• Generally, no access order can be assumed potential livelocks

274



Towards synchronization

Semaphores in POSIX

int sem_init (sem_t *sem_location, int pshared, unsigned int value);int sem_destroy (sem_t *sem_location);

int sem_wait (sem_t *sem_location);int sem_trywait (sem_t *sem_location);int sem_timedwait (sem_t *sem_location, const struct timespec *abstime);

int sem_post (sem_t *sem_location);

int sem_getvalue (sem_t *sem_location, int *value);

pshared is actually a Boolean indicating whether the

semaphore is to be shared between processes

aarerrre

tionaional Universitl Univ y page 274 ofy 758 (chapter 3: “Communication & Synchronization” u8tiionaonaonal Universitl Univerl U ill U il U iU i itUniversityy page 274 ofyy 758 (chapter 3: “Communication & Synchronization” u8

*value indicates the number of waiting processes as a

negative integer in case the semaphore value is zero

270




Semaphores in Ada

package Ada.Synchronous_Task_Control is

type Suspension_Object is limited private;

procedure Set_True (S : in out Suspension_Object); procedure Set_False (S : in out Suspension_Object); function Current_State (S : Suspension_Object) return Boolean; procedure Suspend_Until_True (S : in out Suspension_Object);

private … ------ not specified by the languageend Ada.Synchronous_Task_Control;

only one task can be blocked at Suspend_Until_True! (Program_Error will be raised with a second task trying to suspend itself)

no queues! minimal run-time overhead

chronous_Task_Control is

Obj t i li it d private;

out Suspension_Object);outt SuspeSuspeSuspSuspeSuspeSuspeSuspepuspeuspensnnsnsinsion_nsnsinsnsnsn ion_ObjectObjecObjectbjectjjectject ;););););));))))

SusSSusSusSusSusSusSusSussusususuususssspenspenpensipenspensiopensiensensensensensensensensensnnn on_nn_n_On_n_O_Ob_O_OOO t)t)ct)ct)ct)ct)ct)ct)ct)ct)ct)ct)t) rerererereturreturetureturetureturneetureturneturneturneturneturnturnturnturnurn BBBBBBBBBB n;nnnnnnnnn;n;n;n;;;;;;;;;pend_Until_True (S : in outoututututttt SuspSuspeSuspeSuspeSuspeSuspeSuspSuspSuspSuspSuspSuspSuspSuspSuspSusSuspSususususpepepensionnsionnsionnsionnsionnsionnsionnsionnsionnsiionionnsinsiiisiiiiiiono cctctctctctectectbjectbjectjectectectcttcttt););))));)););;

specicified bfiedfied bfied bd bd bd bd d bbbbby y they the y they they they they the y they they they thetheth aauaaauaaaaaaageggggegenousnnous_nousous_ous_ous_sous_Ts Ts Tsussus Ts_Tsss_Ts_TTTTask_Coask_Coask_Coask_Cosk_Cosk_Co_Cask_Coask_Coask_Cosk_Cosk_Cok_Co_Co_Co_Co_Co_CoCC tttt ;;tttrotrotrotrotrotrotrotrotrotrotrorrorr ;;;

bee blo blobloblobloblobloblobloblobloblobloolooolooocked acked ckedckedckedckedckedckedcked ackedcked aked at t SuspenS d_Until_True! l be raibe raised with a second task trying to suspend itself)

oooooooleoleooleoleoleooooleoleoleololeolelelllleObjeObjeObjeObjebjejObjebjejbjjeeOOOObjecObjecObjecObjecObjeObjeObjeObjeObObjebjebbjebjebjebjebjbjbjj

langlanglanglanglanglanglanglanglanglanglanglanglanganganananananan

eeeeBooleBooleBooleBoBooleBooleBooleBooleooleooleooleoooleooleooo an;an;an;an;aanananaananananananant););));););;;;;;;)))) returrerrreturreturreturreturreturretuetuuuuuuu_Ob

n_Obj_Obje_Obj_Obje_ObjeObjObjeObjeObjeObjeObjeeejeebj ctctctccccctctcccctctn_n_nn_________ObjectObjectObjecObjectObjecObjecObjecObjectObjectObjecObjecObjecbjecObjecObjecObjecebjebjecnnnnsnsnsnnsnsnsnsssssssisiss

eneeennnnSSSSSuSSuSuSuSuSuSuSuuuu

SuSuSSuSuSuuuuuuususususus

gegegegeeeeeeeeeeeeeeggggge e e e gualangualangualangualangualangulanglanguuagugguaguggguguauaoooool;oololol;l;l;l;ll;l;l;l;oooooooouu

d bbbyyy yyyyyous_Tous_Tus_Tus_Tus_Ts_Ts_Ts_T_TT_T_TTTTask_Coask_Coask_Coask_Coask Coask_Coask_Coaskask_Coask_Coask Coask Coask_Cosksk_Cosk Cokk Cok nntntntntntntnt

bbbbbbbbblololololololo

ii

procedure Susppend Until True (S : in o

t S i Obj t i limit d

on Currprocedprocedprocedprocedprocedproceproceproceprocedprocprocedproceprocedprocedprocedrocedrocerocedrocededureure SuspS

rrrrririririrrrririrrriiiiv

nn oin oo

rent_Stent_Stent_Stent_Stent_Stent_Stent_Se t_ent_Stent_Stnt_Stnt_Stt_Stt_Stt_St___ ateateateateateateateateateaate ateateateatetete eee e (S(S(S(S(S(S(S((S(S((S(((((SSSSS ::pend Until True (S : in oo

type Suspensioon_Object is limitedd

procedprocedprocedprocedprocedprocedprocedprocedrocerocedo ureureureureureurrr Set_SetSete procedure Set_ function Curr

bject is limiteimiteiteteteedddddd prprprprprppppr

_TTTrue (S : in_False (S : inrent St t

for special cases only … otherwise:

283




Monitors with condition synchronization(Hoare ‘74)

Hoare-monitors:

• Condition variables are implemented by semaphores (Wait and Signal).

• Queues for tasks suspended on condition variables are realized.

• A suspended task releases its lock on the monitor, enabling another task to enter.

More effi cient evaluation of the guards: the task leaving the monitor can evaluate all guards and the right tasks can be activated.

Blocked tasks may be ordered and livelocks prevented.

279




process producer;

loop

region critial_buffer_region when buffer.size < N do ------ place in buffer etc. end region;

end loop;end producer;

process consumer;

loop

region critial_buffer_region when buffer.size > 0 do ------ take from buffer etc. end region;

end loop;end consumer;

Conditional Critical Regions

buffer : buffer_t;resource critial_buffer_region : buffer;

275




Semaphores in POSIXsem_t mutex, cond[2];typedef emun {low, high} priority_t;int waiting;int busy;

void allocate (priority_t P){ sem_wait (&mutex); if (busy) { sem_post (&mutex); sem_wait (&cond[P]); } busy = 1; sem_post (&mutex);}

void deallocate (priority_t P){ sem_wait (&mutex); busy = 0; sem_getvalue (&cond[high], &waiting); if (waiting < 0) { sem_post (&cond[high]); } else { sem_getvalue (&cond[low], &waiting); if (waiting < 0) { sem_post (&cond[low]); } else { sem_post (&mutex);} } }

Deadlock?

Livelock?

Mutual exclusion?

271




Malicious use of "queueless semaphores"with Ada.Synchronous_Task_Control; use Ada.Synchronous_Task_Control;X : Suspension_Object;

task B;task body B isbegin … Suspend_Until_True (X); … …end B;

task A;task body A isbegin … Suspend_Until_True (X); … …end A;

Could raise a Program_Error as multiple tasks potentially suspend on the same semaphore(occurs only with high effi ciency semaphores which do not provide process queues)

284




Monitors with condition synchronizationmonitor buffer;

export append, take;

var BUF : array [ … ] of integer; top, base : 0..size-1; NumberInBuffer : integer; spaceavailable, itemavailable : condition;

procedure append (I : integer); begin if NumberInBuffer = size then wait (spaceavailable); end if; BUF [top] := I; NumberInBuffer := NumberInBuffer + 1; top := (top + 1) mod size; signal (itemavailable) end append; …

280




Review of Conditional Critical Regions

• Well formed synchronization blocks and synchronization conditions.

• Code, data and synchronization primitives are associated (known to compiler and runtime).

• All guards need to be re-evaluated, when any conditional critical region is left:

all involved processes are activated to test their guards

there is no order in the re-evaluation phase potential livelocks

• Condition synchronisation inside the critical code sectionsrequires to leave and re-enter a critical region.

• As with semaphores the conditional critical regions are distributed all over the code.

on a larger scale: same problems as with semaphores.

(The language Edison (Per Brinch Hansen, 1981) uses conditional critical regions for synchroniz-ation in a multiprocessor environment (each process is associated with exactly one processor).)

276




Semaphores in Java (since 2004)

Semaphore (int permits, boolean fair)

void acquire () void acquire (int permits) void acquireUninterruptibly (int permits) boolean tryAcquire () boolean tryAcquire (int permits, long timeout, TimeUnit unit)

int availablePermits ()protected void reducePermits (int reduction) int drainPermits ()

void release () void release (int permits)

protected Collection <Thread> getQueuedThreads () int getQueueLength () boolean hasQueuedThreads () boolean isFair () String toString ()

wait

signal

check and manipulate

administration

}}}}gg

}ong tgg}n}nngggggng}n}ngggng

}}}}}

}}}}

272




Malicious use of "queueless semaphores"with Ada.Synchronous_Task_Control; use Ada.Synchronous_Task_Control;X, Y : Suspension_Object;

task B;task body B isbegin … Suspend_Until_True (Y); Set_True (X); …end B;

task A;task body A isbegin … Suspend_Until_True (X); Set_True (Y); …end A;

Will result in a deadlock (assuming no other Set_True calls)

285




Monitors with condition synchronization… procedure take (var I : integer); begin if NumberInBuffer = 0 then wait (itemavailable); end if; I := BUF[base]; base := (base+1) mod size; NumberInBuffer := NumberInBuffer-1; signal (spaceavailable); end take;begin (* initialisation *) NumberInBuffer := 0; top := 0; base := 0end;

The signalling and the

waiting process are both

active in the monitor!

281




Monitors(Modula-1, Mesa — Dijkstra, Hoare)

Basic idea:

• Collect all operations and data-structures shared in critical regions in one place, the monitor.

• Formulate all operations as procedures or functions.

• Prohibit access to data-structures, other than by the monitor-procedures and functions.

• Assure mutual exclusion of all monitor-procedures and functions.

277




Review of semaphores• Semaphores are not bound to any resource or method or region

Compiler has no idea what is supposed to be protected by a semaphore.

• Semaphores are scattered all over the code

Hard to read and highly error-prone.

Adding or deleting a single semaphore operation usually stalls a whole system.

Semaphores are generally considered inadequate for non-trivial systems.

(all concurrent languages and environments offer effi cient and higher-abstraction synchronization methods)

Special (usually close-to-hardware) applications exist.

273




Malicious use of "queueless semaphores"with Ada.Synchronous_Task_Control; use Ada.Synchronous_Task_Control;X, Y : Suspension_Object;

task B;task body B isbegin … Suspend_Until_True (Y); Suspend_Until_True (X); …end B;

task A;task body A isbegin … Suspend_Until_True (X); Suspend_Until_True (Y); …end A;

Will potentially result in a deadlock (with general semaphores) or a Program_Error in Ada.

298




void Reader()

{ try {

Monitor::Enter (data_to_protect); Monitor::Wait (data_to_protect); … read out protected data } finally { Monitor::Exit (data_to_protect); } };

void Writer()

{ try {

Monitor::Enter (data_to_protect); … write protected data Monitor::Pulse (data_to_protect); } finally { Monitor.Exit (data_to_protect); } };

Monitors in Visual C++using namespace System;using namespace System::Threading

private: integer data_to_protect;

294




Monitors in POSIX (‘C’)(operators)

…

int pthread_mutex_lock ( pthread_mutex_t *mutex);int pthread_mutex_trylock ( pthread_mutex_t *mutex);int pthread_mutex_timedlock ( pthread_mutex_t *mutex, const struct timespec *abstime);

int pthread_mutex_unlock ( pthread_mutex_t *mutex);

int pthread_cond_wait ( pthread_cond_t *cond, pthread_mutex_t *mutex);int pthread_cond_timedwait ( pthread_cond_t *cond, pthread_mutex_t *mutex, const struct timespec *abstime);

int pthread_cond_signal ( pthread_cond_t *cond);int pthread_cond_broadcast ( pthread_cond_t *cond);

can be called

• any time

• anywhere

• multiple times

(((( pthread_mutex_t *mutex);ppthread mutex t *mutex);

((( ( (((( ( (

k

( pthread mutex t *mutex);

ppthrethread_mutex_t *mutex);mumutex t *mutex

(( (( (( ( ( (( ppppppthththrthrthr( ( pthreadthreadthreadthreadthreadthreadh

(( pthread mutex t *mutex);

( ( pppppppptthreadthreadthreadthreadthreadthreade __mutex_ utex_t *mutex,constst strucstrucstrucstrucstrucstrucstruct tt timet timet timet timet timet timespec *specspecspec *aabstimabstimab e);

( pthread mutex t *mutex);ex);))

eadadadreadeada _mute_mutex_mutmut_mut_muec ****abstabsabstabstibstbstst

pthread_mutex_t *mutex);t (

((((( p );(((( pthread cond t *cond);

;; *co*co*co*cococond,nd,nd,ndndndnddd,,

d_mutex_mutex_mutex_mutexmutexmutexutex_t *mu_t *mu_t *mu_t *mu_t *mu_t *mu_t *mm tex,tetttstrucstrucstrucstrucstrucstructruct timet timet timet timet timet timet timespec *spespssps abstime);

( ((((( pppppppthreadthrethrththtthrh _cond_t *cond);

pthread_mutex_t *mutex);( pthread_cond_t *co d

pthread_muteconst stru

290




Monitors in POSIX (‘C’)(types and creation)

Synchronization between POSIX-threads:

typedef … pthread_mutex_t;typedef … pthread_mutexattr_t;typedef … pthread_cond_t;typedef … pthread_condattr_t;

int pthread_mutex_init ( pthread_mutex_t *mutex, const pthread_mutexattr_t *attr);int pthread_mutex_destroy ( pthread_mutex_t *mutex);

int pthread_cond_init ( pthread_cond_t *cond, const pthread_condattr_t *attr);int pthread_cond_destroy ( pthread_cond_t *cond);…

adadad

adadad

)

dd__mutex_t *mutex,ddd__mutexattr_t *attr);d_d__mutex_t *mutex);

d___cond_t *cond,d___condattr_t *attr);d___cond_t *cond);

Attributes include:

• semantics for trying to lock a mutex which

is locked already by the same thread

• sharing of mutexes and

condition variables between processes

• priority ceiling

• clock used for timeouts

• …

286




Monitors with condition synchronization

Suggestions to overcome the multiple-tasks-in-monitor-problem:

• A signal is allowed only as the last action of a process before it leaves the monitor.

• A signal operation has the side-effect of executing a return statement.

• Hoare, Modula-1, POSIX: a signal operation which unblocks another process has the side-effect of blocking the cur-rent process; this process will only execute again once the monitor is unlocked again.

• A signal operation which unblocks a process does not block the caller, but the unblocked process must re-gain access to the monitor.

299




Public Sub Reader

Try

Monitor.Enter (data_to_protect) Monitor.Wait (data_to_protect) … read out protected data Finally Monitor.Exit (data_to_protect) End TryEnd Sub

Public Sub Writer

Try

Monitor.Enter (data_to_protect) … write protected data Monitor.Pulse (data_to_protect) Finally Monitor.Exit (data_to_protect) End TryEnd Sub

Monitors in Visual BasicImports SystemImports System.Threading

Private Dim data_to_protect As Integer = 0

295




#define BUFF_SIZE 10typedef struct { pthread_mutex_t mutex; pthread_cond_t buffer_not_full; pthread_cond_t buffer_not_empty; int count, first, last; int buf [BUFF_SIZE]; } buffer;

int append (int item, buffer *B) { PTHREAD_MUTEX_LOCK (&B->mutex); while (B->count == BUFF_SIZE) { PTHREAD_COND_WAIT ( &B->buffer_not_full, &B->mutex); } PTHREAD_MUTEX_UNLOCK (&B->mutex); PTHREAD_COND_SIGNAL ( &B->buffer_not_empty); return 0;}

int take (int *item, buffer *B) { PTHREAD_MUTEX_LOCK (&B->mutex); while (B->count == 0) { PTHREAD_COND_WAIT ( &B->buffer_not_empty, &B->mutex); } PTHREAD_MUTEX_UNLOCK (&B->mutex); PTHREAD_COND_SIGNAL ( &B->buffer_not_full); return 0;}

291









Undefi ned while locked

r_t;

( pthp recoconconconstconcoco pthre

((( pthre

291 f 758 ( h 3 “C i i & S8291 f 58 ( h 3 “C i i & S8

Undefi ned while threads are waiting

(

287




Monitors in Modula-1

• procedure wait (s, r): delays the caller until condition variable s is true (r is the rank (or ‘priority’) of the caller).

• procedure send (s): If a process is waiting for the condition variable s, then the process at the top of the queue of the highest fi lled rank is activated (and the caller suspended).

• function awaited (s) return integer: check for waiting processes on s.

300




public void reader throws InterruptedException {

mon.enter(); Condvar.await(); … read out protected data mon.leave(); }

public void writer

throws InterruptedException {

mon.enter(); … write protected data Condvar.signal(); mon.leave(); }

Monitors in JavaMonitor mon = new Monitor();

Monitor.Condition Condvar = mon.new Condition();

Unnnniversitniversiniversitniversitniveiversitiversitiversiiversitvversitversiter tyyyyyyyyyy page 300 opage 300 opage 300 o30300300e 300 f fffyyyyyyy 75875875877755 (chapter ( h t( h 3888

… the Java library monitor

connects data or condition

variables to the monitor

by convention only!

296




#define BUFF_SIZE 10typedef struct { pthread_mutex_t mutex; pthread_cond_t buffer_not_full; pthread_cond_t buffer_not_empty; int count, first, last; int buf [BUFF_SIZE]; } buffer;

int append (int item, buffer *B) { PTHREAD_MUTEX_LOCK (&B->mutex); while (B->count == BUFF_SIZE) { PTHREAD_COND_WAIT ( &B->buffer_not_full, &B->mutex); } PTHREAD_MUTEX_UNLOCK (&B->mutex); PTHREAD_COND_SIGNAL ( &B->buffer_not_empty); return 0;}

int take (int *item, buffer *B) { PTHREAD_MUTEX_LOCK (&B->mutex); while (B->count == 0) { PTHREAD_COND_WAIT ( &B->buffer_not_empty, &B->mutex); } PTHREAD_MUTEX_UNLOCK (&B->mutex); PTHREAD_COND_SIGNAL ( &B->buffer_not_full); return 0;}

ot empty;oot_t_t_ pempty;empty;p y;p

need to be called

with a locked mutexr;

buffer *B) { {{{{&B->mutex)tex)tex)ex)ex)x)x);;;UFFF_SIZE)_SIZE)_SIZE_SI_SIZE_SIZESIZ {(((

mmppppppppp

}}}

while (B->count = 0) {whilehile (B c(B->c(B ount =ount =unt = 0) {= 0) {= 0) { 0) {0) {PTHREAD_COND_WAIT (

&B->buffer_not_em &B->mutex);

}

better to be called

after unlocking all mutexes

(as it is itself potentially blocking)B->mutex);

K (&B->B >>>mutex)mutex)mutex)mutex)mutexmutex)mutex);;((((((((((((

292





…





ppppppthreadhreadreead_con_cond_condcond__cond__con __cond_cond_condcond_ond_ond__t ct *ct *cot *cot co*co *co *coc*co**cccoo ,nd,nd,ndndnndndndndd,dddd,h

pppppthreadthreadthreadhrre _cond_condcondcondcondd t *cot *cot *cond,nd pthread_mutex_t *mutex);

pthread cond t *co d

unblocks ‘at least one’ thread

(

consccc

eadead cond t *cond);eadeadeadddeadddeaeadd condcondcondcondddc dcondconddd t *cot *cot *ttt * nd);d)d)ddd

rureadreadreeadead_mutexmutmutexmutmutete _t *mut *mut *mutex,textucucccct timespec *abstime);

,dunblocks all threads

( ppppppthrethrthrththrthr(( (((((((((( pthre( rererrererree

288




Monitors in Modula-1INTERFACE MODULE resource_control;

DEFINE allocate, deallocate;

VAR busy : BOOLEAN; free : SIGNAL;

PROCEDURE allocate; BEGIN IF busy THEN WAIT (free) END; busy := TRUE; END;

PROCEDURE deallocate; BEGIN busy := FALSE; SEND (free); ------ or: IF AWAITED (free) THEN SEND (free); END;

BEGIN busy := false;END.

301




Monitors in Java(by means of language primitives)

Java provides two mechanisms to construct a monitors-like structure:

• Synchronized methods and code blocks: all methods and code blocks which are using the synchronized tag are mutually exclusive with respect to the addressed class.

• Notifi cation methods: wait, notify, and notifyAll can be used only in synchronized regions and are waking any or all threads, which are waiting in the same synchronized object.

297




static void Reader()

{ try {

Monitor.Enter (data_to_protect); Monitor.Wait (data_to_protect); … read out protected data } finally { Monitor.Exit (data_to_protect); } }

static void Writer()

{ try {

Monitor.Enter (data_to_protect); … write protected data Monitor.Pulse (data_to_protect); } finally { Monitor.Exit (data_to_protect); } }

Monitors in C#using System;using System.Threading;

static long data_to_protect = 0;

293





…





*mumutex,te**mu*mu*mu*mu**mu**mu**mu*m*mu*mu*mummmmuutex,textextexttextextetex,teeexexexeexexexxxx

*abstime);*abstime);;

***mutex);

****cond,***mutex);****c*cond,

undefi ned

if called ‘out of order’

i.e. mutex is not lockedpppppppthreadthreadthreadthreadthreadthreadhreadre _mutexmutemummmu _t ( ( (( (((( pthread_cond_t

**

((((((( ppppthreadthreadthreadthrea _mutex_mutex_t *

( h d d *_cond__cond_ond_nd_nd_ond_t t t tt **(((((( pppppppthreadthreadthreadthreadthreathreahreadhread_condcondcondcondcondcondond t

289









314




Criticism of monitors

• Mutual exclusion is solved elegantly and safely.

• Conditional synchronization is on the level of semaphores still all criticism about semaphores applies inside the monitors

Mixture of low-level and high-level synchronization constructs.

310




Monitors in Java

Per Brinch Hansen (1938-2007) in 1999:

Java’s most serious mistake was the decision to use the sequential part of the language to implement the run-time support for its paral-lel features. It strikes me as absurd to write a compiler for the sequen-tial language concepts only and then attempt to skip the much more diffi cult task of implementing a secure parallel notation. This wish-ful thinking is part of Java’s unfortunate inheritance of the insecure C language and its primitive, error-prone library of threads methods.

"Per Brinch Hansen is one of a handful of computer pioneers who was responsible for advan-cing both operating systems development and concurrent programming from ad hoc tech-niques to systematic engineering disciplines." (from his IEEE 2002 Computer Pioneer Award)

306




Monitors in Java(multiple-readers-one-writer-example: usage of external conditional variables)

… public void StartWrite () throws InterruptedException {

synchronized (OkToWrite) {

synchronized (this) {

if (writing | readers > 0) { waitingWriters++; OkToWrite.wantToSleep = true; } else { writing = true; OkToWrite.wantToSleep = false; } }

if (OkToWrite.wantToSleep) OkToWrite.wait (); } } …

302





Considerations:

1. Synchronized methods and code blocks:• In order to implement a monitor all methods in an object need to be synchronized.

any other standard method can break a Java monitor and enter at any time.

• Methods outside the monitor-object can synchronize at this object.

it is impossible to analyse a Java monitor locally, since lock ac-cesses can exist all over the system.

• Static data is shared between all objects of a class.

access to static data need to be synchronized with all objects of a class.

Synchronize either in static synchronized blocks: synchronized (this.getClass()) {…}or in static methods: public synchronized static <method> {…}

315




Synchronization by protected objectsCombine

the encapsulation feature of monitorswith

the coordinated entries of conditional critical regionsto:

Protected objects

• All controlled data and operations are encapsulated.

• Operations are mutual exclusive (with exceptions for read-only operations).

• Guards (predicates) are syntactically attached to entries.

• No protected data is accessible (other than by the defi ned operations).

• Fairness inside operations is guaranteed by queuing (according to their priorities).

• Fairness across all operations is guaranteed by the "internal progress fi rst" rule.

• Re-blocking provided by re-queuing to entries (no internal condition variables).

311




Object-orientation and synchronizationSince mutual exclusion, notifi cation, and condition synchronization schemes need to be de-signed and analyzed considering the implementation of all involved methods and guards:

New methods cannot be added without re-evaluating the class!

Re-usage concepts of object-oriented programming do not translate to synchronized classes (e.g. monitors) and thus need to be considered carefully.

The parent class might need to be adapted in order to suit the global synchronization scheme.

Inheritance anomaly (Matsuoka & Yonezawa ‘93)

Methods to design and analyse expandible synchronized systems exist, yet they are complex and not offered in any concurrent programming language.Alternatively, inheritance can be banned in the context of synchronization (e.g. Ada).

307





… public void StopWrite () {

synchronized (OkToRead) {



if (waitingWriters > 0) { waitingWriters--; OkToWrite.notify (); // wakeup one writer } else { writing = false; OkToRead.notifyAll (); // wakeup all readers readers = waitingReaders; waitingReaders = 0; } } } } } …

303





Considerations:

2. Notifi cation methods: wait, notify, and notifyAll• wait suspends the thread and releases the local lock only

nested wait-calls will keep all enclosing locks.

• notify and notifyAll do not release the lock!

methods, which are activated via notifi cation need to wait for lock-access.

• Java does not require any specifi c release order (like a queue) for wait-suspended threads

livelocks are not prevented at this level (in opposition to RT-Java).

• There are no explicit conditional variables associated with the monitor or data.

notifi ed threads need to wait for the lock to be released and to re-evaluate its entry condition.

316




Synchronization by protected objects(Simultaneous read-access)

Some read-only operations do not need to be mutually exclusive:

protected type Shared_Data (Initial : Data_Item) is

function Read return Data_Item; procedure Write (New_Value : Data_Item);

private The_Data : Data_Item := Initial;end Shared_Data_Item;

• protected functions can have ‘in’ parameters only and are not allowed to alter the private data (enforced by the compiler).

protected functions allow simultaneous access (but mutual exclusive with other operations).

… there is no defi ned priority between functions and other protected operations in Ada.

312




Monitors in POSIX, Visual C++, C#, Visual Basic & Java All provide lower-level primitives for the construction of monitors.

All rely on convention rather than compiler checks.

Visual C++, C+ & Visual Basic offer data-encapsulation and connection to the monitor.

Java offers data-encapsulation (yet not with respect to a monitor).

POSIX (being a collection of library calls) does not provide any data-encapsulation by itself.

Extreme care must be taken when employing object-oriented programming and synchronization (incl. monitors)

308





… public void StartRead () throws InterruptedException {

synchronized (OkToRead) {


if (writing | waitingWriters > 0) { waitingReaders++; OkToRead.wantToSleep = true; } else { readers++; OkToRead.wantToSleep = false; } }

if (OkToRead.wantToSleep) OkToRead.wait (); } } …

304





Standard monitor solution:

• declare the monitored data-structures private to the monitor object (non-static).

• introduce a class ConditionVariable:

public class ConditionVariable { public boolean wantToSleep = false; }

• introduce synchronization-scopes in monitor-methods:

synchronize on the adequate conditional variables fi rst and

synchronize on the adequate monitor-object second.

• make sure that all methods in the monitor are implementing the correct synchronizations.

• make sure that no other method in the whole system is synchronizing on or interfering with this monitor-object in any way by convention.

317




Synchronization by protected objects(Condition synchronization: entries & barriers)

Condition synchronization is realized in the form of protected procedurescombined with boolean predicates (barriers): called entries in Ada:

Buffer_Size : constant Integer := 10;

type Index is mod Buffer_Size;subtype Count is Natural range 0 .. Buffer_Size;type Buffer_T is array (Index) of Data_Item;

protected type Bounded_Buffer is

entry Get (Item : out Data_Item); entry Put (Item : Data_Item);

private First : Index := Index’First; Last : Index := Index’Last; Num : Count := 0; Buffer : Buffer_T;end Bounded_Buffer;

313




Nested monitor callsAssuming a thread in a monitor is calling an operation in another monitor and is suspended at a conditional variable there:

the called monitor is aware of the suspension and allows other threads to enter.

the calling monitor is possibly not aware of the suspension and keeps its lock!

the unjustifi ed locked calling monitor reduces the system performance and leads to potential deadlocks.

Suggestions to solve this situation:

• Maintain the lock anyway: e.g. POSIX, Java

• Prohibit nested monitor calls: e.g. Modula-1

• Provide constructs which specify the release of a monitor lock for remote calls, e.g. Ada

309





… public void StopRead () {



readers--; if (readers == 0 & waitingWriters > 0) { waitingWriters--; OkToWrite.notify (); } } } }}

305





public class ReadersWriters {

private int readers = 0; private int waitingReaders = 0; private int waitingWriters = 0; private boolean writing = false;

ConditionVariable OkToRead = new ConditionVariable (); ConditionVariable OkToWrite = new ConditionVariable ();…

330



Shared memory based synchronization

POSIX

• All low level constructs available

• Connection with the actual data-struc-tures by means of convention only

• Extremely error-prone

• Degree of non-determinism intro-duced by the ‘release some’ semantic

• ‘C’ based

• Portable

330 f 758 ( h t 3 “C i ti & S h i ti ” t age 369)8

Semaphores(atomic P, V ops)

Flags(atomic word access)

Synchronized methods

(mutual exclusion)Conditional variables

Conditional critical regions

Monitors

Data structure encapsulation

Protected objects

Guards (barriers)

326




Synchronization by protected objects(Entry families, requeue & private entries)

How to moderate the fl ow of incoming calls to a busy server farm?

type Urgency is (urgent, not_so_urgent); type Server_Farm is (primary, secondary);

protected Pre_Filter is entry Reception (U : Urgency);

private entry Server (Server_Farm) (U : Urgency); end Pre_Filter;

322




Synchronization by protected objects(Operations on entry queues)

The count attribute indicates the number of tasks waiting at a specifi c queue:

protected Block_Five is

entry Proceed;

private Release : Boolean := False;

end Block_Five;

protected body Block_Five is

entry Proceed when Proceed’count > 5 or Release is

begin Release := Proceed’count > 0; end Proceed;

end Block_Five;

318




Synchronization by protected objects(Condition synchronization: entries & barriers)

protected body Bounded_Buffer is

entry Get (Item : out Data_Item) when Num > 0 is

begin Item := Buffer (First); First := First + 1; Num := Num - 1; end Get;

entry Put (Item : Data_Item) when Num < Buffer_Size is

begin Last := Last + 1; Buffer (Last) := Item; Num := Num + 1; end Put;

end Bounded_Buffer;

331




Java

• Mutual exclusion available.

• General notifi cation feature (not connected to other locks, hence not a conditional variable)

• Universal object orientation makes local analysis hard or even impossible

• Mixture of high-level object oriented features and low level concurrency primitives

331 f 758 ( h t 3 “C i ti & S h i ti ” t 369)8






Monitors


Protected objects

Guards (barriers)

327





protected body Pre_Filter is

entry Reception (U : Urgency) when Server (primary)’count = 0 or else Server (secondary)’count = 0 is

begin

If U = urgent and then Server (primary)’count = 0 then requeue Server (primary);

else requeue Server (secondary); end if;

end Reception;

entry Server (for S in Server_Farm) (U : Urgency) when True is

begin null; -- might try something even more useful end Server;

end Pre_Filter;

323




Synchronization by protected objects(Operations on entry queues)

The count attribute indicates the number of tasks waiting at a specifi c queue:

protected type Broadcast is

entry Receive (M: out Message); procedure Send (M: Message);

private New_Message : Message; Arrived : Boolean := False;

end Broadcast;

protected body Broadcast is

entry Receive (M: out Message) when Arrived is

begin M := New_Message Arrived := Receive’count > 0; end Proceed;

procedure Send (M: Message) is

begin New_Message := M; Arrived := Receive’count > 0; end Send;end Broadcast;

319




Synchronization by protected objects(Withdrawing entry calls)

Buffer : Bounded_Buffer;

select Buffer.Put (Some_Data);

or delay 10.0; -- do something after 10 s.

end select;

select Buffer.Get (Some_Data);

else -- do something else

end select;

332




C#, Visual C++, Visual Basic

• Mutual exclusion via library calls (convention)

• Data is associated with the locks to protect it

• Condition variables related to the data protection locks

• Mixture of high-level object oriented features and low level concurrency primitives

332 f 758 ( h t 3 “C i ti & S h i ti ” t 369)8






Monitors


Protected objects

Guards (barriers)

328




Synchronization by protected objects(Restrictions for protected operations)

All code inside a protected procedure, function or entry is bound to non-blocking operations.

Thus the following operations are prohibited:

• entry call statements

• delay statements

• task creations or activations

• select statements

• accept statements

• … as well as calls to sub-programs which contain any of the above

The requeue facility allows for a potentially blocking operation, and releases the current lock!

324





Additional, essential primitives for concurrent control fl ows:

• Entry families:A protected entry declaration can contain a discrete subtype selector, which can be evaluated by the barrier (other parameters cannot be evaluated by barriers) and implements an array of protected entries.

• Requeue facility:Protected operations can use ‘requeue’ to redirect tasks to other internal, external, or private entries. The current protected operation is fi nished and the lock on the object is released.

‘Internal progress fi rst’-rule: external tasks are only considered for queuing on barriers once no internally requeued task can be progressed any further!

• Private entries:Protected entries which are not accessible from outside the protected object, but can be employed as destinations for requeue operations.

320




Synchronization by protected objects(Withdrawing entry calls)

Buffer : Bounded_Buffer;

select Buffer.Put (Some_Data);

or delay 10.0; -- do something after 10 s.

end select;


else -- do something else

end select;


then abort -- meanwhile try something else

end select;

select delay 10.0;

then abort Buffer.Put (Some_Data); -- try to enter for 10 s.

end select;

333




C++14

• Mutual exclusion in scopes

• Data is not strictly associated with the locks to protect it

• Condition variables related to the mutual exclusion locks

• Set of essential primitives without combin-ing them in a syntactically strict form (yet?)

333 f 758 ( h t 3 “C i ti & S h i ti ” t 369)8




(mutual exclusion) Conditional variables

Conditional critical regionsMonitors


Protected objects

Guards (barriers)

329




General

Criteria:

• Levels of abstraction

• Centralized versus distributed

• Support for automated (compiler based)consistency and correctness validation

• Error sensitivity

• Predictability

• Effi ciency

page 329 of 758 (chapter 3 “Comm nication & S nchroni ation” p to page 369)8






Monitors


Protected objects

Guards (barriers)

325




Synchronization by protected objects(Entry families)

package Modes is

type Mode_T is (Takeoff, Ascent, Cruising, Descent, Landing);

protected Mode_Gate is procedure Set_Mode (Mode: Mode_T); entry Wait_For_Mode (Mode_T);

private Current_Mode : Mode_Type := Takeoff; end Mode_Gate;

end Modes;

package body Modes is

protected body Mode_Gate is procedure Set_Mode (Mode: Mode_T) is

begin Current_Mode := Mode; end Set_Mode;

entry Wait_For_Mode (for Mode in Mode_T) when Current_Mode = Mode is

begin null; end Wait_For_Mode;

end Mode_Gate;

end Modes;

321




Synchronization by protected objects(Barrier evaluation)

Barrier in protected objects need to be evaluated only on two occasions:

• on creating a protected object, all barrier are evaluated according to the initial values of the internal, protected data.

• on leaving a protected procedure or entry, all potentially altered barriers are re-evaluated.

Alternatively an implementation may choose to evaluate barriers on those two occasions:

• on calling a protected entry, the one associated barrier is evaluated.

• on leaving a protected procedure or entry, all potentially altered barriers with tasks queued up on them are re-evaluated.

Barriers are not evaluated while inside a protected object or on leaving a protected function.

346



Message-based synchronization

Message protocols

Remote invocation

• Delay sender or receiver until the fi rst rendezvous point

• Pass parameters

• Keep sender blocked while receiver executes the local procedure

• Pass results

• Release both processes out of the rendezvous

e 346 of 758 (chapter 3 “Comm nication & S nchroni ation” p to page 369)8

invocation

results

asyncronous

syncronoustime time

remote invocation

342




Message protocols

Synchronous message(receiver waiting)

Delay the receiver process until

• Sender becomes available

• Sender concludes transmission


send

receive

asyncronous

syncronoustime time

338



Current developments

Atomic operations in X10X10 offers only atomic blocks in unconditional and conditional form.

• Unconditional atomic blocks are guaranteed to be non-blocking, which means that they cannot be nested and need to be implemented using roll-backs.

• Conditional atomic blocks can also be used as a pure notifi cation system (similar to the Java notify method).

• Parallel statements (incl. parallel, i.e. unrolled ‘loops’).

• Shared variables (and their access mechanisms) are not defi ned.

• The programmer does not specify the scope of the locks (atomic blocks) but they are managed by the compiler/runtime environment.

Code analysis algorithms are required in order to provide effi ciently, otherwise the runtime environment needs to associate every atomic block with a global lock.

334




Rust

• Mutual exclusion in scopes

• Data is strictly associated with locks to protect it

• Condition variables related to the mutual exclusion locks

• Combined with the message passing semantics already a power set of tools.

• Concurrency features migrated to a standard library.

page 334 of 758 (chapter 3 “Communication & Synchronization” up to page 369)8




(mutual exclusion) Conditional variables

Conditional critical regionsMonitors


Protected objects

Guards (barriers)

347




Message protocols

Remote invocation(simulated by asynchronous messages)

• Simulate two synchronous messages

• Processes are never actually synchronized


send

receive

sendreceive

sendreceive

send receive

asyncronous

syncronoustime time

343




Message protocols

Asynchronous message

Neither the sender nor the receiver is blocked:

• Message is not transferred directly

• A buffer is required to store the messages

• Policy required for buffer sizes and buffer overfl ow situations


send

receive

asyncronous

syncronoustime time

339



Current developments

Synchronization in ChapelChapel offers a variety of concurrent primitives:

• Parallel operations on data (e.g. concurrent array operations)

• Parallel statements (incl. parallel, i.e. unrolled ‘loops’)

• Parallelism can also be explicitly limited by serializing statements

• Atomic blocks for the purpose to construct atomic transactions

• Memory integrity needs to be programmed by means of synchronization statements (waiting for one or multiple control fl ows to complete) and/or atomic blocks

Further Chapel semantics are still forthcoming … so there is still hope for a stronger shared memory synchronization / memory integrity construct.

335




Modula-1, Chill, Parallel Pascal, …

• Full implementation of the Dijkstra / Hoare monitor concept

The term monitor appears in many other concurrent languages, yet it is usually not associated with an actual language primitive.







Monitors


Protected objects

Guards (barriers)

348




Message protocols

Remote invocation (no results)

Shorter form of remote invocation which does not wait for results to be passed back.

• Still both processes are actually synchronized at the time of the invocation.


invocation

asyncronous

syncronoustime time

remote invocation

344




Message protocols

Asynchronous message(simulated by synchronous messages)

Introducing an intermediate process:

• Intermediate needs to be ac-cepting messages at all times.

• Intermediate also needs to send out messages on request.

While processes are blocked in the sense of synchronous message passing, they are not ac-tually delayed as the intermediate is always ready.


send

receive

time time

receive

send

time

340



Synchronization


Synchronization model• Asynchronous

• Synchronous

• Remote invocation

Addressing (name space)• direct communication

• mail-box communication

Message structure• arbitrary

• restricted to ‘basic’ types

• restricted to un-typed communications

336




Ada

• High-level synchronization support which scales to large size projects.

• Full compiler support incl. potential deadlock analysis

• Low-Level semaphores for very special cases

Ada has still no mainstream competitor

in the fi eld of explicit concurrency.(2018)


s






Monitors


Protected objects

Guards (barriers)

349




Message protocols

Remote invocation (no results)(simulated by asynchronous messages)

• Simulate one synchronous message

• Processes are never actually synchronized


send

receive

sendreceive

asyncronous

syncronoustime time

345




Message protocols

Synchronous message(simulated by asynchronous messages)

Introducing two asynchronous messages:

• Both processes voluntarily suspend them-selves until the transaction is complete.

• As no immediate communication takes place, the processes are never actually synchronized.

• The sender (but not the receiver) process knows that the transaction is complete.


send

receive

sendreceive

asyncronous

syncronoustime time

341




Message protocols

Synchronous message(sender waiting)

Delay the sender process until

• Receiver becomes available

• Receiver acknowledges reception


send

receive

asyncronous

syncronoustime time

337



High Performance Computing

Synchronization in large scale concurrencyHigh Performance Computing (HPC) emphasizes onkeeping as many CPU nodes busy as possible:

Avoid contention on sparse resources.

Data is assigned to individual processes rather than processes synchronizing on data.

Data integrity is achieved by keeping the CPU nodes in approximate “lock-step”, yet there is still a need to re-sync concurrent entities.

Traditionally this has been implemented using the Message Passing Interface (MPI) while implementing separate address spaces.

Current approaches employ partitioned address spaces, i.e. memory spaces can overlap and be re-assigned. Chapel, Fortress, X10.

Not all algorithms break down into independent computation slices and so there is a need for memory integrity mechanisms in shared/partitioned address spaces.

362


© 2020 Uwe R. Zimmer, The Australian National University page 362 of 758 (chapter 3: “Communication & Synchronization” up to page 369)© 2020 Uwe R. Zimmer, The Australian National University page 362 ofy 758 (chapter 3: Communication & Synchronization up to page 369)8© 2020 Uwe© 2020 Uwe© 2020 U©© 2020 U R ZimmerR ZimmerR ZiR Zi The AustralThe AustralTh A t lTh A lian Nationaian Nationai N tii N i l Universitl Universitl U i itl U i i yy page 362 opage 362 o362362 ffffyy 758758758758 (chapter(chapter( h t( h 3: Communi3: “Communi3 “C i3 “C ication & Sycation & Syti & Si & S nchronizatinchronizatih i tih i ion up to pon” up to p” t” age 369)age 369)369)369)8888


Message-based synchronization in CHILLCHILL is the ‘CCITT High Level Language’,

where CCITT is the Comité Consultatif International Télégraphique et Téléphonique.

The CHILL language development was started in 1973 and standardized in 1979. strong support for concurrency, synchronization, and communica-tion (monitors, buffered message passing, synchronous channels)

dcl SensorBuffer buffer (32) int;

…send SensorBuffer (reading);

receive case (SensorBuffer in data) : …esac;

send SensorChannel (reading) to consumer

receive case (SensorChannel in data): …esac;

signal SensorChannel = (int) to consumertype;…

(((((S(((S((readi(readireadireadirreadingngngngng)))););))););)));;asynchronous

((((((S(((S((synchronous

358




Message-passing systems examples:

ord

ered

sym

met

rica

l

asym

met

rica

l

syn

chro

no

us

asyn

chro

no

us

dir

ect

ind

irec

t

contents on

e-to

-on

e

man

y-to

-on

e

man

y-to

-man

y

methodPOSIX: byte-stream message queues

MPI: memory-blocks message passingCHILL: basic types message passing

Occam2: fully typed message passingAda: fully typed remote invocationGo: fully typed channels

Erlang: fully typed message passingJava: no message passing system defi ned

354




Message structure

• Machine dependent representations need to be taken care of in a distributed environment.

• Communication system is often outside the typed language environment.

Most communication systems are handling streams (packets) of a basic element type only.

Conversion routines for data-structures other then the basic element type are supplied …

… manually (POSIX, C)

… semi-automatic (CORBA)

… automatic (compiler-generated) and typed-persistent (Ada, CHILL, Occam2)

350




Synchronous vs. asynchronous communications

Purpose ‘synchronization’: synchronous messages / remote invocationsPurpose ‘last message(s) only’: asynchronous messages

Synchronous message passing in distributed systems requires hardware support.

Asynchronous message passing requires the usage of buffers and overfl ow policies.

Can both communication modes emulate each other?

363




Message-based synchronization in Ada

Ada supports remote invocations ((extended) rendezvous) in form of:

• entry points in tasks

• full set of parameter profi les supported

If the local and the remote task are on different architectures, or if an intermediate communication system is employed then:

parameters incl. bounds and discriminants are ‘tunnelled’ through byte-stream-formats.

Synchronization:

• Both tasks are synchronized at the beginning of the remote invocation ( ‘rendezvous’)

• The calling task if blocked until the remote routine is completed ( ‘extended rendezvous’)

359




Message-based synchronization in Occam2Communication is ensured by means of a ‘channel’, which:

• can be used by one writer and one reader process only

• and is synchronous:

CHAN OF INT SensorChannel:PAR INT reading: SEQ i = 0 FOR 1000 SEQ -- generate reading SensorChannel ! reading INT data: SEQ i = 0 FOR 1000 SEQ SensorChannel ? data -- employ data

concurrent entities are

synchronized at these pointsg

355




Message structure (Ada)

package Ada.Streams is pragma Pure (Streams); type Root_Stream_Type is abstract tagged limited private; type Stream_Element is mod implementation-defined; type Stream_Element_Offset is range implementation-defined;

subtype Stream_Element_Count is Stream_Element_Offset range 0..Stream_Element_Offset’Last;

type Stream_Element_Array is array (Stream_Element_Offset range <>) of Stream_Element;

procedure Read (…) is abstract; procedure Write (…) is abstract;

private … -- not specified by the languageend Ada.Streams;

351




Synchronous vs. asynchronous communications

Purpose ‘synchronization’: synchronous messages / remote invocationsPurpose ‘last message(s) only’: asynchronous messages

Synchronous message passing in distributed systems requires hardware support.

Asynchronous message passing requires the usage of buffers and overfl ow policies.

Can both communication modes emulate each other?

• Synchronous communications are emulated by a combination of asynchronous messages in some systems (not identical with hardware supported synchronous communication).

• Asynchronous communications can be emulated in synchronized message passing systems by introducing a ‘buffer-task’ (de-coupling sender and receiver as well as allowing for broadcasts).

364




Message-based synchronization in Ada(Rendezvous)

<entry_name> [(index)] <parameters> ------ waiting for synchronization ------ waiting for synchronization ------ waiting for synchronization ------ waiting for synchronization ------ accept <entry_name> [(index)]

<parameter_profile>;--- aaasynchronized

© 20© 2© 2©©©

<<<

time time

360




Message-based synchronization in Occam2Communication is ensured by means of a ‘channel’, which:

• can be used by one writer and one reader process only

• and is synchronous:

CHAN OF INT SensorChannel:PAR INT reading: SEQ i = 0 FOR 1000 SEQ -- generate reading SensorChannel ! reading INT data: SEQ i = 0 FOR 1000 SEQ SensorChannel ? data -- employ data

Essential Occam2 keywords

ALT PAR SEQ PRI

ANY CHAN OF

DATA TYPE RECORD OFFSETOF PACKED

BOOL BYTE INT REAL

CASE IF ELSE FOR FROM WHILE

FUNCTION RESULT PROC IS

PROCESSOR PROTOCOL TIMER

SKIP STOP VALOFa

page 360 of 758 (chapter 3: “Communication & Synchronization” up to page 369)8 Concurrent, distributed, real-time programming language!

356




Message structure (Ada)Reading and writing values of any subtype S of a specifi c type T to a Stream:

procedure S’Write (Stream : access Ada.Streams.Root_Stream_Type’Class; Item : in T);

procedure S’Class’Write (Stream : access Ada.Streams.Root_Stream_Type’Class; Item : in T’Class);

procedure S’Read (Stream : access Ada.Streams.Root_Stream_Type’Class; Item : out T);

procedure S’Class’Read (Stream : access Ada.Streams.Root_Stream_Type’Class; Item : out T’Class)

Reading and writing values, bounds and discriminants of any subtype S of a specifi c type T to a Stream:

procedure S’Output (Stream : access Ada.Streams.Root_Stream_Type’Class; Item : in T);

function S’Input (Stream : access Ada.Streams.Root_Stream_Type’Class) return T;

352




Addressing (name space)

Direct versus indirect:send <message> to <process-name>wait for <message> from <process-name>send <message> to <mailbox>wait for <message> from <mailbox>

Asymmetrical addressing:send <message> to …wait for <message>

Client-server paradigm

365




Message-based synchronization in Ada(Extended rendezvous)

<entry_name> [(index)] <parameters> ------ waiting for synchronization ------ waiting for synchronization ------ waiting for synchronization ------ waiting for synchronization ------ ------ blocked ------ blocked ------ blocked ------ blocked ------

accept <entry_name> [(index)] <parameter_profile> do ------ remote invocation ------ remote invocation ------ remote invocation end <entry_name>;

---bl k d

aaa

--- ee

synchronized

return results

© 20© 2© 2©©©

<<<

time time

361


© 2020 Uwe R. Zimmer, The Australian National University page 361 of 758 (chapter 3: “Communication & Synchronization” up to page 369)© 2020 Uwe© 2020 Uwe R. Zimmer,R Zimmer The AustralThe Australian Nationaian National Universitl Universityy page 361 opage 361 offyy 758758 (chapter(chapter 3: Communi3: Communication & Sycation & Synchronizatinchronization up to pon up to page 369)age 369)88© 2020 Uwe©© 2020 Uwe© 2020 U©© 2020 U R ZimmerR ZimmerR ZiR Zi The AustralThe AustralTh A t lTh A lian Nationaian Nationai N tii N i l Universitl Universitl U i itl U i i yy page 361 opage 361 o361361 ffffyy 75875875858 (chapter(chapter( h t( h 3: Communi3: “Communi3 “C i3 “C ication & Sycation & Syti & Si & S nchronizatinchronizatih i tih i ion up to pon” up to p” t” age 369)age 369)369)369)8888


Message-based synchronization in CHILLCHILL is the ‘CCITT High Level Language’,

where CCITT is the Comité Consultatif International Télégraphique et Téléphonique.

The CHILL language development was started in 1973 and standardized in 1979. strong support for concurrency, synchronization, and communica-tion (monitors, buffered message passing, synchronous channels)

dcl SensorBuffer buffer (32) int;

…send SensorBuffer (reading);

receive case (SensorBuffer in data) : …esac;

send SensorChannel (reading) to consumer

receive case (SensorChannel in data): …esac;

signal SensorChannel = (int) to consumertype;…

357




Message-passing systems examples:

POSIX: “message queues”: ordered indirect [asymmetrical | symmetrical] asynchronous

byte-level many-to-many message passingMPI: “message passing”:

ordered [direct | indirect] [asymmetrical | symmetrical] asynchronous memory-block-level [one-to-one | one-to-many | many-to-one | many-to-many] message passing

CHILL: “buffers”, ”signals”: ordered indirect [asymmetrical | symmetrical] [synchronous | asynchronous]

typed [many-to-many | many-to-one] message passingOccam2: “channels”:

ordered indirect symmetrical synchronous fully-typed one-to-one message passingAda: “(extended) rendezvous”:

ordered direct asymmetrical [synchronous | asynchronous]fully-typed many-to-one remote invocation

Java: no message passing system defi ned

353




Addressing (name space)

Communication medium:

Connections Functionality

one-to-one buffer, queue, synchronization

one-to-many multicast

one-to-all broadcast

many-to-one local server, synchronization

all-to-one general server, synchronization

many-to-many general network- or bus-system

366




Message-based synchronization in Ada(Rendezvous)

<entry_name> [(index)] <parameters>

accept <entry_name> [(index)] <parameter_profile>; ------ waiting for synchronization ------ waiting for synchronization ------ waiting for synchronization

synchronized

© 20© 2©© 2©©©© 2

<<<

time time

367




Message-based synchronization in Ada(Extended rendezvous)

<entry_name> [(index)] <parameters> ------ blocked ------ blocked ------ blocked ------ blocked ------

accept <entry_name> [(index)] <parameter_profile>; ------ waiting for synchronization ------ waiting for synchronization ------ waiting for synchronization

------ remote invocation ------ remote invocation ------ remote invocation ------ remote invocation end <entry_name>;

remott------------ remotremotremotremotootottototttsynchronized

© 20© 2©© 2©©©©

<<<

time time

ee --- return results

368




Message-based synchronization in Ada

Some things to consider for task-entries:

• In contrast to protected-object-entries, task-entry bodies can call other blocking operations.

• Accept statements can be nested (but need to be different).

helpful e.g. to synchronize more than two tasks.

• Accept statements can have a dedicated exception handler (like any other code-block).

Exceptions, which are not handled during the rendezvous phase are propagated to all involved tasks.

• Parameters cannot be direct ‘access’ parameters, but can be access-types.

• ‘count on task-entries is defi ned, but is only accessible from inside the tasks which owns the entry.

• Entry families (arrays of entries) are supported.

• Private entries (accessible for internal tasks) are supported.

369



Summary


• Shared memory based synchronization

• Flags, condition variables, semaphores, conditional critical regions, monitors, protected objects.

• Guard evaluation times, nested monitor calls, deadlocks, simultaneous reading, queue management.

• Synchronization and object orientation, blocking operations and re-queuing.

• Message based synchronization

• Synchronization models

• Addressing modes

• Message structures

• Examples

CDS-03 Communication & Synchronization · 2020. 9. 1. · Towards synchronization process P1;...

Documents

Transcript of CDS-03 Communication & Synchronization · 2020. 9. 1. · Towards synchronization process P1;...