hs-ha

7/31/2019 HS-HA

1/20

26.11.19 99 HS-HA.doc

Half Sync / Half Async 1

Douglas C. Schmidt 1998, 1999, all rights reserved, Siemens AG 1998, 1999, all rights reserved

Half Syn c/ Half Asy nc

Th e Ha lf-S y nc/ Half-A s y nc archi tectura l pa t te rn decoup les synchro-

nou s tasks from asynch ronous ta sks in complex concu rrent sys tems .

Example An operating system is a widely-used example of a complex

concur rent s ystem th at m an ages man y different types of app lications

and hardware . For ins tance , i t coordina tes and demult ip lexes thecomm un ica t ion b e tween s tan dard In tern e t n e tworking ap pl ica t ions ,

s u c h a s telnet, ftp, smtp, dns, and inetd, and ha rdware I/ O

devices, such as network interfaces, disk controllers , end-user

terminals , and printers . The operating system is responsible for

ma na ging th e schedu ling, comm un ica t ion, protect ion, an d m emory

allocation of all its concur rent ly execut ing a pplications an d h ard ware

devices.

One way to imp lemen t a highly efficient operating system is to drive

it entirely by asynchronous interrupts . This design is efficient

becau se it ma ps directly onto the event n otification m echan ism u sedby most h ard ware devices. For ins tan ce, pack ets ar riving on n etwork

interfaces can be delivered asynchronously to the operating system

by hardware in terrupts , processed asynchronous ly by higher- layer

protocols , su ch as TCP/ IP, and fina lly consu med b y applications ,

s u c h a s telnet or ftp, which can be not ified by asynchronous

s igna ls , su ch as SIGIO [Ste97].

FTP INETD DNS

TELNET SMTP

Operating System

Applications

Hardware

7/31/2019 HS-HA

2/20

2


26.11.19 99 HS-HA.doc

Experience has shown, however, that i t is hard to develop complex

concurrent sys tems tha t a re based ent i re ly on asynchronous

processing. In particular, the effort required to program, validate,

debug, an d m ainta in as ynchronous appl ica t ions can be proh ibit ive ly

expensive, tedious, and error-prone. Therefore, many software

developers prefer to u se synchr onous program ming techniques , su ch

as m u lti-thr eading or mu lti-processing, which m ay be easier to lear n

and un de rs tand than a synchronous t echn iques , such a s s igna l s o r

in terrupts .

Unfortunately, basing complex concurrent systems entirely on

synchronous process ing often m akes i t ha rd to m eet s t r ingent qu al ity

of service requiremen ts . This problem s tems from th e add itiona l t ime

an d spa ce overhead a ssociated with imp lem enta tions of synch ronou s

multi-threading or multi-processing techniques. These synchronous

techniques are typically less efficient because they add more

abstraction layers between asynchronously triggered hardware

devices, operating system services , a nd higher -level applications.

Thus, a key challenge facing developers of complex concurrent

sys tems is how to s t ruc ture asynchronous and synchronous

processing in order to reconcile th e n eed for program ming s implicity

with th e need for high qu ality of service. There is a s tron g in cent ive to

use a synchronous processing model to s implify application

program ming. Likewise, there is a s tr ong incen tive to us e asyn chron y

to im pr ove qu ality of service.

Context A comp lex concurren t sys tem tha t performs both asynch ronous a nd

synchronous process ing.

Problem Complex concu rren t systems are often ch ara cterized by a m ixtur e of

a synchronous and synchronous t a sks tha t mus t be p roces sed a t

various levels of abstraction. These types of systems require the

simultaneous resolution of the following two forces :

Cer ta in t a sks in complex concur ren t sys tems m us t be p roces sedasyn chr onou sly in order to s atisfy qua lity of service requiremen ts .

For instance, protocol processing within an operating system

kern el is typically asynch ronou s becau se I/ O devices ar e driven by

interrupts that are triggered by the network interface hardware. If

these asynchronous in terrupts a re not handled immedia te ly the

7/31/2019 HS-HA

3/20

26.11.19 99 HS-HA.doc



hardware may function incorrectly by dropping packets or

corru pt ing h ardware r egis te rs a nd mem ory buffers .

It is ha rd, h owever, to write complex program s wh ere all tas ks are

triggered entirely by asynchronous interrupts . In particular,

asynchron y can cau se su bt le t iming problems an d ra ce condi t ions

when a thread of control i s preempted by an in terrupt handler .

Moreover, in addition to a ru n -tim e stack, asynch ronou s program s

often require da ta s t ruc tures tha t conta in addi t ional s ta te

inform at ion. When in terrupts occur , program mers m u s t sa ve and

restore th ese data s tru ctu res explicit ly, which is tedious a nd error-

prone . In addi t ion , i t i s hard to debug asynchronous programs

because interrupts can occur at different, often non-repeatable,

points of t ime du ring program execution.

In contrast , i t may be easier to write synchronous programs

becau se task s can b e cons trained to occu r at well-defined points in

the process ing sequence . For ins tance , programs tha t use

synchronous read() a n d write() system calls can block awaiting

th e completion of I/ O operations. The u se of blocking I/ O allows

programs to maintain s tate information and execution his tory in

the ir run - t ime ac t iva t ion r ecord s ta ck, ra ther th an in s epara te da ta

s t ru c tures th a t m u s t be m an aged by program mers explic it ly .

Althou gh synchronous p rogram s are genera l ly eas ier to write ,

there are circumstances where quality of service requirements

cannot be achieved if many or all tasks are processed

synchronously within separate threads of control. The problem

stems from th e fac t tha t each th read conta ins resources , such as

a run-time stack, a set of regis ters , and thread-specific s torage,

that must be created, s tored, retrieved, synchronized, and

destroyed by a thread manager. A non-trivial amount of t ime and

space may be required to manage threads. For example, if an

opera t ing sys tem associa tes a separa te thread to process each

ha rdware I / O device synch ronous ly with in th e kern e l, the thread

management overhead can be excessive.

In contrast , i t may be more efficient to write asynchronous

program s becau se tasks can b e map ped direc t ly onto h ardware or

software in terru pt h an dlers . For ins tan ce, asynchronous I/ O

based on in terrupt-dr iven DMA enables communica t ion and

computation to proceed s imultaneously and efficiently. Likewise,

7/31/2019 HS-HA

4/20

4


26.11.19 99 HS-HA.doc

asynchronou s sys tems s t ru c tured u s ing in terru pts ma y incu r less

overhead from context switching [SchSu95] than equivalent

synchronous sys tems s t ruc tu red us ing th reads because the

inform at ion needed to mainta in p rogram s ta te can be redu ced.

Alth ough th e need for both program ming simp licity and high qu ality

of service ma y appear to conflict , it is essen tial that both th ese forces

be resolved effectively in complex concurrent systems.

Solution Decompose the tasks in the system into three layers: synchronous ,

asynchronous , and queueing . Process h igher- layer tasks , such as

database queries or file transfers , synchronously in separa te threadsor processes in order to s implify concurrent programming.

Conversely, process lower-layer tasks, such as servicing interrupts

from network inter faces, asynchronously in order to enha nce qua lity

of service. Communication between tasks residing in the separate

synchronous and asynchronous layers should be media ted by a

queueing layer.

Structure The pa rticipan ts in th e Half-Sync/ Half-Async pa ttern includ e the

following:

A sy nchronous tas k lay erperform s h igh-level processing ta sks . Tasks

in the synchronous layer run in separa te threads or processes tha thave their own run-time stack and regis ters . Therefore, they can

block while perform ing synch ronou s operations, su ch as I/ O. For

ins ta nce , appl ica t ion pr ocesses can u se read() a n d write() system

calls to per form I/ O synch ronou sly for th eir h igh-level tas ks.

An asynchronous task layer performs lower-level processing tasks,

which typically eman ate from mu ltiple extern al I/ O sou rces. Tasks in

the asynchronous layer do not have a dedica ted run-t ime s tack or

regis ters . Thus, they cannot block indefinitely while performing

asynchronou s opera t ions . For ins tance , I/ O devices an d pr otocol

processing in operating system kern els typically perform th eir ta sks

asynchronou s ly, often in in terru pt h an dlers .A queueing layerprovides a b u ffering point between th e synchr onou s

task layer an d th e asynchronou s ta sk layer . Messages pr oduced by

asynchronous tasks a re buffered a t the queueing layer for subse-

qu ent retrieval by synch ronou s tas ks a nd vice versa. In add ition, the

queueing layer is responsible for notifying tasks in one layer when

7/31/2019 HS-HA

5/20

26.11.19 99 HS-HA.doc



messages are passed to them from the other layer. For instance, op-

erating systems typically provide a socket layer that serves as the

bu ffering an d n otification p oint b etween th e synchr onou s ap plication

processes an d the as ynchronous I/ O hard ware devices in th e kerne l.

Ex te rn a l I/ O s ou rces genera te events t ha t are received an d processed

by the asynchronous task layer. For example, network interfaces,

d isk control le rs , and end-user te rminals a re common sources of

externa l I/ O events for operating system s.

The following s implified UML class diagram illu stra tes th e s tr u ctur e

an d r e la t ionsh ips be tween th ese par t ic ipan ts .

Cla ss

Queuing Layer

Re s p o n s ib i l i t y

Provides a bu ffe r ing

between th esynchronous t as k layer and th easynchronous t ask layer

C olla bor a to r

As yn c h ro n ou sTask Layer

S yn c h ron ou s

Task Layer

Cla ss

Asynchronous

Task Layer

Re s p o n s i b i l i t y

Execu tes low-leve lprocess ing ta sksasynchronous ly

C olla bor a to r

Q u e u in g La ye r

Cla ss

Synchronous

Task Layer

Re s p o n s ib i l i t y

Execu tes h igh- lev-el processing taskssynchronous ly

C olla bor a to r

Q u e u in g La ye r

Cla ss

Externa l

I/ O Source

Re s p o n s i b i l i t y

G en e ra t es e ve n tsreceived an dprocessed by theasynchronous t ask layer

C olla bor a tor

As yn c h r on o u sTask Layer

Sync Task 1 Sync Task 2 Sync Task 3

Queue

Asyn c TaskExternal

Event So urce

SynchronousTask Layer

AsynchronousTask Layer

QueuingLayer

7/31/2019 HS-HA

6/20

6


26.11.19 99 HS-HA.doc

Dynamics Asynch ronou s an d synch ronou s layers in the Half-Sync/ Half-Async

pat te rn in terac t in a producer / cons um er ma nn er by excha nging

messages via a queueing layer. Below, we describe three phases of

interactions th at occur wh en inpu t arr ives bottom-u p from extern al

I/ O sources ,

As y nch ron ou s phas e . In this phase, external sources of input

in terac t wi th the asynchronous task layer v ia in terrupts or

asynchronous event not ifica t ions . When asynchronous tasks a re

finished process ing the i r input they can communica te to the

designa ted task s in the synch ronou s layer via the queu eing layer.

Queueing phase . In this phase, the queueing layer buffers input

pass ed from th e asynchronou s layer to the synchronous layer and

notifies the synchr onou s layer tha t inp u t is available.

Sy nchronous phase . In th is ph ase , tasks in the synchronou s layer

retrieves and processes input placed into the queueing layer by

tasks in th e asynchronou s layer.

The interactions between layers and components is s imilar when

outp u t ar rives top-down from tas ks in th e synch ronou s layer.

: External I/ O

Source

: Asyn c Tas k : Que ue

notification

read()

enqueues()

message

: Sync Task

work()

message

read()

message

work()

notification

7/31/2019 HS-HA

7/20

26.11.19 99 HS-HA.doc



Implementation This s ection describes h ow to imp lemen t th e Half-Sync/ Half-Async

pat te rn by fac tor ing out tasks in a complex concurren t sys tem into

synchronous and asynchronous layers tha t communica te sole ly

through a queueing layer.

1 Decom pos e th e ov era ll s y s te m in to th ree lay ers : synchronous ,

asynchronous, and queueing. The following criteria can be used to

determine where various tasks are configured into a system

arch itectu re designed according to the Half-Sync/ Half-Async pa ttern .

1 .1 Iden tif y h igh er-level or lon g-d ura tion ta s k s and con fi gu re th em in to th e

synchronous layer. Many tas ks in a complex concurrent sys tem areeasier to implement using synchronous processing. Often, these

tasks perform relatively high-level or long-duration application

processing, su ch as tr an sferring large s tream s of dat a 1 or perform ing

database queries . Tasks in the synchronous layer may block for

prolon ged p eriods a waiting resp onses in accordan ce with app lication

protocols . If the data is not yet available, these synchronous tasks

can b lock at th e queu eing layer un til th e data a rrives.

1 .2 Iden tif y low er-level or s hort-d ura tion ta s k s and con fi gu re th em in to th e

asynchronous layer. Other tasks in a system cannot block for

prolonged periods of time. Often, these tasks perform lower-level or

short -dura t ion sys tem process ing tha t in terac ts wi th externa lsources of events , such as graphical user interfaces or interrupt-

driven hardware network interfaces. To increase efficiency and

ensure response-time, these sources of events must be serviced

rapidly without blocking. Thus, these tasks are triggered by

asyn chron ous n otifications or interru pts from external I/ O sources

an d ru n to comple t ion, a t which point they can inser t th e ir resu lts

int o the qu eueing layer.

1 .3 Iden tif y in te r-lay er com m unica tion ta s k s and con fig ure th em in to th e

queueing layer. The qu eueing layer is a mediator [GHJ V95] tha t

exchanges messages be tween tasks in the asynchronous and

synchronous layers . The protocols u sed by tasks in the synchr onousan d as ynch ronous layers to exchange messa ges is or thogonal to the

tasks performed by the queueing layer. Tasks associated with the

1. The Web server exam ple from th e Proactor pa t tern d escript ion (121) il lus t ra tes

these types of long-dura t ion operat ions .

7/31/2019 HS-HA

8/20

8


26.11.19 99 HS-HA.doc

queueing layer include buffering and notification, layer-to-layer flow

control, an d da ta copying.

2 Im plem ent th e th ree lay ers . The t hr ee layers in th e Half-Sync/ Half-

Async pa ttern can be implement ed as follows.

2 .1 Im plem ent th e s y nch ron ou s lay er. A common way to implement

higher-level or long-dur ation ta sks is to u se th e Active Object pa ttern

(269). The Active Object pattern decouples method execution from

method invocation to s implify synchronized access to a shared

resource by methods invoked in different threads of control. Thus,

ac t ive objects can block, su ch a s when performing synchr onous I/ O,because th ey have the i r own ru n-t ime s tack an d regis te rs .

Im plem ent th e as y nch ron ou s lay er. These lower-level or shorter-

dura t ion tasks can be implemented us ing pas s ive ob jects , which

borrow their thread of control from elsewhere, such as the call ing

thread or a separa te in terrupt s tack. Therefore , to ensure adequate

response t ime for o ther sys tem ta sks , s uch as h igh-pr ior i ty har dware

interrupts , these tasks mus t run asynchronous ly and cannot b lock

for long periods of time. There are several ways to process

asynchronous t a sks :

Dem ultip lex even ts from exte rn a l s ou rces us ing th e Reactor or

Proactor patterns . The Reactor pattern (97) is responsible for

dem u ltiplexing and dispa tching of m u ltiple event h an dlers tha t are

triggered when it is possible to init iate an operation without

blocking. The Proactor pattern (121) supports the demultiplexing

and dispatching of multiple event handlers that are triggered by

the completion of asynchronous operations. The behavior of both

pat tern s is s imilar, however, in th at a ha nd ler can not b lock for long

periods of t ime without disrupting the processing of other event

sources .

Im plem ent a m ulti-le vel in te rrupt s ch em e . These implementations

allow non-time crit ical processing to be interrupted by higher-

priority tasks, such as hardware interrupts , if higher priorityevents must be handled before the current processing is done. To

prevent in terrup t h an dlers f rom corru pt ing shared s ta te whi le they

are be ing accessed, da ta s t ruc tures used by the asynchronous

layer must be protected, such as by rais ing the processor priority

or by u sing sema ph ores [WS95].

7/31/2019 HS-HA

9/20

26.11.19 99 HS-HA.doc



2 .2 Im plem ent th e qu euein g lay er. For input processing, messages are

typically pu sh ed from th e asynch ronou s ta sk layer to the qu eueing

layer, where th e synch ronou s ta sk layer then pu lls th e mess ages

from th e queu eing layer. These roles ar e reversed for ou tpu t process-

ing. The following topics mu st b e add ressed when implementing th e

queu eing layer.

Defi ne th e qu euein g lay er's bu fferin g and not ifi ca tion m ech an is m s .

The presence of multiple CPUs, preemptive multi-threading, or

asynchronous hardware in terrupts enable the s imul taneous

execut ion of tasks in the asynchronous and synchronous layer .

Therefore, concurrent access to internal queue message buffers

must be serialized to avoid race conditions. In addition, i t is

necessary to notify a task in one layer when messages are passed

to i t from an other layer.

The bu ffering an d notification m echan ism s provided by the qu eue-

ing layer are typically implemented using synchronization primi-

t ives , such as semaphores , mutexes , and condi t ion var iables .

These mechanisms ensure tha t messages can be inser ted and re-

moved to and from the queueing layer 's message buffers without

corrupting internal data s tructures . Likewise, these synchroniza-

t ion m echa nisms can be us ed to not ify the appropria te tasks when

dat a h as a rrived for them in th e queu eing layer.

Th e Message_Queue componen ts in th e exam ples from th e Monitor

Object (299) and Active Object (269) patterns illustrates various

techn iqu es for implemen ting a qu eueing layer.

Defi ne a lay er-to-la y er fl ow con trol m ech an is m . Sys tems can not de-

vote an unlimited amount of resources to buffer messages in the

qu eueing layer. Therefore, i t is n ecessary to regulate th e am oun t of

da ta tha t i s passed be tween the synchronous and asynchronous

layers . Layer-to-layer flow control is a techn iqu e th at prevents s yn-

chronous tasks f rom flooding the asynchronous layer a t a fas te r

ra te than messages can be t ransm it t ed an d queued on n e twork in -terfaces [SchS u 93].

Tasks in the synchronous layer can block. Thus , a common flow

control policy is to put a task to s leep if i t produces and queues

more than a cer ta in am oun t of da ta . When th e asynchr onous tas k

layer drains the queue below a certain level the synchronous task

7/31/2019 HS-HA

10/20

1 0


26.11.19 99 HS-HA.doc

can be awaken ed to cont inu e . In contras t , tasks in th e asynchro-

nous layer cannot block. Therefore, if they produce an excessive

am oun t of data a comm on flow control policy is to ha ve th e queu e-

ing layer discard m essa ges. If th e mess ages ar e ass ociated with a

reliable connection-oriented transport protocol, such as TCP, the

sen der will eventu ally t imeout an d retra ns mit.

Min im iz e d a ta copy in g ov erhead. Some sys tems , such as BSD

UNIX, place the qu eueing layer at t he b oun dar y between u ser -level

and kernel-level protection domains. A common way to decouple

these protection domains is to copy messages from user to kernel

and vice versa. However, this increases system bus and memory

load, which may degrade performance s ignificantly when large

messa ges a re m oved across protect ion d omains .

One way to redu ce data copying is to allocate a region of memory

tha t i s shared be tween the synchronous task layer and the

asyn chr onou s t ask layer [DP93]. This d esign allows t he two layers

to exchange data directly, without copying data in the queueing

layer. For exam ple, [CP95] presen ts an I/ O su bsystem t ha t

minimizes boundary-crossing penalties by using polled interrupts

to impr ove the h an dling of cont inu ous media I/ O s t ream s . In

addi t ion , th is appr oach provides a bu ffer ma na gemen t sys tem th a t

a l lows efficient p age remapping an d s ha red m emory mechan ism s

to be used between application processes , the kernel, and i ts

devices.

Example

Resolved

The BSD UNIX operating system [MBKQ96] [Ste97] demultiplexes

an d coordina tes comm un ica t ion b e tween ap pl ica t ion pr ocesses an d

I/ O device ha rdwar e controlled by th e BSD UNIX kernel. In th e

following, we illustrate how the BSD UNIX applies the Half-Sync/

Half-Async pa ttern to receive data t hr ough its TCP/ IP protocol s ta ck

over Eth ern et. We focus on th e synch ronou s invocation of a read()

system ca ll , as ynchr onou s reception an d protocol processing of dat a

7/31/2019 HS-HA

11/20

26.11.19 99 HS-HA.doc

Half Sync / Half Async 1 1


arriving on a network interface, and synchronous completion of the

read() call.

To reduce the complexity of network programming, application

processes comm only perform I/ O synchronously via read() a n d

write() operations. For in sta nce, an app lication p rocess can receive

its da ta from th e socket layer synchr onou sly u sing the read() system

call . Moreover, an application can make read() calls at any point

during i ts execution. If the data is not available yet, the operating

system ker nel can pu t the process to s leep un til th e data a rrives from

the network, th ereby allowing oth er ap plication processes to proceed

concurrently.

For ins tan ce, consider an app lication p rocess th at receives TCP data

from the connected socket handle. To the application process , the

read() sys tem ca l l on th e conn ect ion ap pears to be a synchronous

operation, for exam ple, the p rocess invokes read() and the da ta i s

re turned subsequent ly . Severa l asynchronous s teps occur to

im plement th is system call, h owever, as described below.

When a read() call is issu ed i t trap s into th e kern el, which vectors i t

synchronously into the network socket code. The thread of control

ends u p in th e kerne l' s soreceive() fun ct ion, which h an dles m an y

types of sockets , su ch as da tagram sockets an d s t ream sockets , an d

tran sfers th e da ta from th e socket qu eue to the u ser. In addi t ion , th is

fu n ction per form s t h e Half-Sync pa rt of the BSD UNIX opera ting

system processing.

Sync App

Socket Queues

ApplicationProcess 1

Sync AppProcess 3

Sync AppProcess 2 Processes

SocketLayer

Async Protoco lProcess ing

BSD UnixKernel

1,4: read(data )

3: enqu eue(data )

2: inter ru pt

NetworkInterface

7/31/2019 HS-HA

12/20

1 2


26.11.19 99 HS-HA.doc

A simp lified des cription ofsoreceive() is sh own below:

/* Receive data from a socket after being invoked

synchronously on behalf of an application

process's read() system call. */

int soreceive ( ... ) {

for (;;) {

if (not enough data to satisfy read request) {

/***** Note! *****

The following call forms the boundary

between the Sync and Async layers. */

sbwait (...); /* wait for data */

}else

break;

}

/* copy data to user's buffer at normal priority */

uiomove (...);

return (error code); /* returns 0 if no error */

}

The code above i l lus t ra tes the boundary be tween the synchronous

application process layer and the asynchronous kernel layer.

Alth ough an app lication process ca n s leep wh ile waiting for da ta, th e

kernel cann ot s leep becau se o ther appl ica t ion processes and I/ O

devices in th e system ma y require its s ervices .

There are two ways the user 's read() opera t ion can be handled by

soreceive(), depending on th e chara c ter is t ics of the socket an d th e

am oun t of da ta in th e socket queue:

Completely s yn chronous . If th e data requ ested by th e app lication is

in th e socket queu e it is copied out imm ediately and t he opera tion

completes synchronously.

Ha lf-s y nch ron ou s and ha lf-a s y nch ron ou s . If the data requested by

the application has not yet arrived, the kernel will call the

sbwait() fu nction to pu t the ap plication p rocess to s leep un til th e

reques ted da ta a rr ives .

Once sbwait() puts the process to s leep, the operating system

sch edu ler will context switch to an other pr ocess th at is ready to run .

To the original application process, however, the read() system call

appears to execute synchronously. When packet(s) containing the

requested data arrive the kernel will process them asynchronously,

as d escribed below. When enou gh data ha s been placed in th e socket

7/31/2019 HS-HA

13/20

26.11.19 99 HS-HA.doc



queu e to satisfy the u ser 's requ est th e kern el will wakeu p th e origina l

process and comple te the read() system call , which returns

synch ronou sly to the app lication.

To m aximize per form an ce within th e BSD UNIX ker n el, all pr ocessin g

tasks a re executed asynchronously becau se I/ O devices are driven b y

hardware in terrupts . For ins tance , packets a rr iv ing on ne twork

int erfaces a re delivered to th e kern el via interr u pt h an dlers init iated

asynchronously by the hardware. These handlers receive packets

from devices and trigger subsequent asynchronous processing of

higher-layer protocols, such as IP, TCP, or UDP. Valid packets

containing app lication d ata are u lt im ately qu eued a t th e socket layer,

where the BSD UNIX kernel schedules and dispatches application

processes wai t ing to produ ce or consu me th e da ta synchronous ly.

For insta nce, th e ha lf-async processing as sociated with an

application's read() system call s tarts with a packet arriving on a

network in terface , which causes an asynchronous hardware

int erru pt. All incoming packet p rocessing is d one in t he con text of an

int erru pt h an dler. It is n ot possible to s leep in th e BSD UNIX kern el

du ring an in terru pt becau se there is n o appl ica t ion pr ocess context

and no dedicated thread of control. Therefore, an interrupt handler

mus t borrow the ca l le r ' s thread of control , such as i t s s tack and

registers . The BSD UNIX kernel uses this s trategy to borrow the

thread of control from interrupt handlers and from application

processes that perform system calls .

Convent ion al version s of BSD UNIX u se a t wo-level in terr u pt s ch em e

to ha nd le pack et processing. Hardware cri t ical processing is done a t

a h igh p riority and less t ime crit ical software pr ocessing is don e at a

lower priority level. This two-level interrupt scheme prevents the

overhead of software protocol processing from delaying the servicing

of o ther ha rdware in terru pts .

The two-level BSD UNIX packet processing scheme is divided into

ha rdw are-sp ecific process ing a n d s oftw are protocol proces s ing. Wh ena pa cket a rr ives on a ne twork in terface it cau ses an in terru pt a t tha t

interface 's interrupt priority. The operating system services the

ha rdware in te r rup t an d then enqueues the packe t on th e inpu t queue

in the protocol layer, such as the IP protocol. A network software

interrupt is then scheduled to service that queue at a lower priority.

Once the network hardware interrupt is serviced, the rest of the

7/31/2019 HS-HA

14/20

1 4


26.11.19 99 HS-HA.doc

pr otocol pr ocessin g is don e at th e lower priority level as lon g as th ere

are n o oth er higher level interru pts p end ing.

If the packet is destined for a local process i t is handed off to the

transport protocol layer. The transport layer performs additional

protocol processing, such as TCP segment reassembly and

acknowledgmen ts . Eventu a l ly , the t ran sport layer appen ds the d a ta

to the r eceive socket qu eue a nd calls sbwakeup(). This ca ll wakes u p

the original process that was s leeping in soreceive() waiting for

da ta on th a t socket queu e . Once th is i s done , the software in terru pt

is finished processing the packet.

The following code illustrates the general flow of control in the BSD

UNIX kernel, starting with ipintr(), up th rough tcp_input(), to

sowakeup(), which forms the boundary be tween the asynchronous

and synchronous layers . The first function is ipintr(), which

ha nd les inbou nd IP packets , a s follows:

int ipintr (...) {

int s;

struct mbuf *m;

/* loop, until there are no more packets */

for (;;) {

/* dequeue next packet */

IF_DEQUEUE (&ipintrq, m);/* return if no more packets

if (m == 0) return; */

if (packet not for us) {

/* route and forward packet */

} else {

/* packet for us... reassemble and call the

protocol input function, i.e.,tcp_input(),

to pass the packet up to the transport

protocol. */

(*inetsw[ip_protox[ip->ip_p]].pr_input)

(m, hlen);

}

}

When a TCP/ IP packet is r eceived by ipintr(), the inetsw()

protocol switch invokes the tcp_input() fu nction, which processes

inbou nd TCP packets :

7/31/2019 HS-HA

15/20

26.11.19 99 HS-HA.doc



int tcp_input (m, iphlen) {

/* Much complicated protocol processing omitted... */

/* We come here to pass data up to the application. */

sbappend (&so->so_rcv, m);

sowakeup((so), &(so)->so_rcv);

/* ... */

}

Th e sowakeup() fun ct ion wakes up the a ppl ica t ion pr ocess th a t was

as leep in read() waiting for da ta to ar rive from a TCP conn ection . As

discussed below, this function forms the boundary between the

asynchronous and synchronous layers .

When incoming da ta is appended to the appropria te socket queue ,

th e sowakeup() is invoked if an application process is asleep waiting

for data to be placed into its buffer.

void sowakeup (so, sb) {

/* ... */

if (an application process is asleep on this queue) {

/***** Note! *****

The following call forms the boundary

between the Async and Sync layers. */

wakeup ((caddr_t) &sb->sb_cc);

}

}

When a p rocess goes to s leep th ere is a ha nd le as sociated with th at

process . To wake u p a s leeping process th e BSD UNIX kernel invokes

th e wakeup() call on that handle. A process waiting for an event will

typica l ly use th e addr ess of the da ta s t ruc tu re re la ted to th a t event as

its handle. In the current example, the address of the socket receive

queue (sb->sc_cc) is u sed as a ha ndle .

If there are no processes waiting for data on a socket queue nothing

interes t ing happen s .2 In our examp le use cas e, however, the origina l

process wa s s leeping in soreceive() waiting for da ta . Th erefore, th e

kern el will wake u p th is process in t he soreceive() fu nction, wh ich

loops back to check if enou gh da ta h as arrived to sa tisfy the read()

operation. If all the data requested by the application has arrived

soreceive() will copy the data to the user 's buffer and the system

call will retur n.To the a pplication process , th e read() call app eared

2. Note that th e kernel never blocks , however, and is a lways doing someth ing

interest ing, even if th at s ometh ing is simply ru nn ing an idle process .

7/31/2019 HS-HA

16/20

1 6


26.11.19 99 HS-HA.doc

to be synchronous , even though asynchronous process ing and

context switching were per form ed while the pr ocess was s leeping.

Variants Combining a sy nchronous notification w ith s yn chronous I/ O. It is pos -

sible for the synchronous task layer to be notified asynchronously

when dat a is bu ffered at t he qu eueing layer. For ins tan ce, the UNIX

SIGIO signa l-driven I/ O mecha nism is implement ed us ing th is tech-

nique [Ste97]. In th is ca se, a s ignal is u sed t o pu sh a n otification to

a h igher -level app lication process . This pr ocess can th en u se read()

to pu ll th e dat a s ynchr onou sly from th e qu eueing layer with out

blocking.Spa w ning sy nchronous threads on-dem and from as yn chronous

handlers . Another way to combine asynchronous notifications with

synchronous I / O is to spawn a th read on-demand when an

asynchronou s opera t ion is invoked. I/ O is then performed

synchronous ly in the new thread. This approach ensures tha t the

resou rces devoted to I/ O tasks a re a fu nction of th e nu mb er of work

reques ts b e ing processed in the s ys tem.

Providing a sy nchronous I/ O to higher-level tas ks . Some sys tems

extend th e pr eceding m odel s t il l fu rth er b y allowing notifications to

push data along to the higher-level tasks. This approach is used in

th e exten ded signa l inter face for UNIX System V Release 4 (SVR4). Inthis case, a buffer pointer is passed along to the handler function

called by the operating system when a s ignal occurs .

Windows NT su pports a s imilar mechan ism u s ing over lapped I / O an d

I/ O com pletion ports [Sol98].In th is case, when a n a synch ronou s

operation comp letes i ts associated overlapped I/ O stru ctur e ind icates

which operation completed and passes any data along. The Proactor

pattern (121) and Asynchronous Completion Token pattern (149)

describes how to s tructure applications to take advantage of

asynchronou s opera t ions an d overlapped I / O.

Providing s yn chronous I/ O to low er-level tas ks . Single-threaded

operating systems, such as BSD UNIX, usually support a hybrid

synchronous / asynchronou s I / O model only for h igher - leve l

application tasks. In these systems, lower-level kernel tasks are

res t r ic ted to as ynchronous I/ O. Mult i- threaded sys tems perm it

synch ronou s I/ O operations in th e kern el if mu ltiple wait contexts

are supported via threads. This is useful for implementing polled

7/31/2019 HS-HA

17/20

26.11.19 99 HS-HA.doc



interrupts , which reduce the amount of context switching for high-

performance cont inuous media sys tems by dedica t ing a kerne l

thr ead t o poll a field in s ha red m emory at r egu lar intervals [CP95].

If th e asynch ronou s ta sk layer possesses its own th read of control it

can ru n au tonomous ly an d u se the queueing layer to pass messa ges

to the synch ronou s tas k layer. Micro-kern el operating systems, su ch

as Mach or Amoeba [Tan95], typically use this design. The micro-

kern el ru ns as a s epara te process th at exchan ges messa ges with

application processes [Bl90].

Known Uses UNIX Networking Subsystems . The BSD UNIX networkingsubsystem [MBKQ96] and the original System V UNIX STREAMS

comm u nication framework [Ri84] us e th e Half-Sync/ Half-Async

pat te rn to s t ru c ture th e concu rrent I / O archi tectu re of appl ica t ion

processes an d th e operating system k ern el. All I/ O in th ese kern els

is asynchronous and triggered by interrupts . The queueing layer is

implemented by the Socket layer in BSD and by STREAM heads in

System V STREAMS. I/ O for ap plication processes is synch ronou s.

Most UNIX network da emon s, su ch a s telnet a n d ftp, ar e developed

as application processes that call the synchronous higher-level

read()/write() system calls. This design shields developers from

the complexity of asyn chr onou s I/ O han dled by th e kern el. Ther e areprovisions for notifications, however, such as the SIGIO signal

mechan ism , tha t can be us ed to t r igger synchr onous I / O

asynchronous ly .

CORBA ORBs . The multi-threaded version of Orbix, MT-Orbix

[Bak97], u ses several variations of the Half-Sync/ Half-Async p atter n

to dispatch CORBA rem ote operations in a concu rren t server. In the

asyn chron ous layer of MT-Orbix, a sepa rate th read is as sociated with

each socket handle that is connected to a client. Each thread blocks

synchronously reading CORBA requests from the client. When a

reques t is received i t is dem u ltiplexed an d inserted into the qu eueing

layer. An active object thread in the synchronous layer then wakesup, dequeues the reques t , and processes i t to comple t ion by

perform ing an u pcall to th e CORBA servant.

ACE. Th e ACE fra m ework [Sch 97 ] u ses t h e Half-Sync/ Half-Asyn c

patt ern in an app lication-level Gateway [Sch9 6] th at r outes mes sages

between peers in a dis tributed system. The Reactor pattern (97) is

7/31/2019 HS-HA

18/20

1 8


26.11.19 99 HS-HA.doc

u sed to im plement an object-orient ed demu ltiplexing an d dispatch ing

mechan ism tha t h an dles indica t ion events asynchronou s ly, the ACE

Message_Queue class implements the queueing layer, and the ACE

Task class implements the Active Object pattern (269) in the

synchronous task layer.

Conduit . The Cond u it comm u nication framework [Zweig90] from th e

Choices operating system project [CIRM93] implements an object-

oriented version of th e Half-Sync/ Half-Asyn c patt ern . App lication

processes a re synch ronou s active objects , an Adap ter Condu it serves

as the queueing layer, and the Conduit micro-kernel operates

asynchronous ly .

Consequences The Half-Sync/ Half-Async pat tern ha s th e following benefit s :

Simp lification a nd performa nce . Higher -level synch ronou s p rocessing

tasks are s implified, without degrading overall system performance.

In comp lex concu rren t systems , there ar e often m an y more high-layer

processing task s th an low-layer tas ks. Therefore, decou pling h igher -

layer synchronous tasks from lower-level asynchronous processing

tasks s implifies the overall system because complex concurrency

control, interru pt h an dling, an d t iming task s can be localized with in

the asynchronous task layer . The asynchronous layer a lso handles

low-level details , such as interrupt handling, that may be hard forapplication developers to program. In addition, the asynchronous

layer can m an age th e interaction with h ard ware-specific compon ents ,

su ch as DMA, memory man agemen t, and I/ O device regis ters .

Moreover, the u se of synch ronou s I/ O can s implify program ming an d

improve performance on multi-processor platforms. For example,

long-duration data transfers , such as downloading a large medical

image from a database [PHS96], can be s implified and performed

efficiently by using synch ronou s I/ O. One pr ocessor can be dedicated

to the thread t ran sferr ing the da ta , which ena bles the ins t ru c t ion an d

data cache of that CPU to be associated with the entire transfer

operation.

Separation of concerns . Synchronization policies in each layer are

decoupled. Ther efore, each layer need not us e the sam e concu rren cy

control strategies. In the single-threaded BSD UNIX kernel, for

ins ta nce , the asynchronou s ta sk layer implements synchroniza t ion

via low-level mechanisms, such as rais ing and lowering CPU

7/31/2019 HS-HA

19/20

26.11.19 99 HS-HA.doc



interrupt levels . In contrast , application processes in the

synchronous task layer implement synchronization via higher-level

mechan ism s , su ch as moni tor objec ts (299) an d m essage qu eues .

For exam ple, legacy librar ies like X win dows a n d Su n RPC ar e often

non-reentrant. Therefore, multiple threads of control cannot safely

invoke these l ibrary functions concurrently. However, to ensure

quality of service or to take advantages of multiple CPUs, it may be

necessary to perform bulk da ta t ransfers or da tabase quer ies in

separa te th reads . The Half-Sync/ Half-Async pa t te rn can be u sed to

decouple the s ingle-threaded portions of an application from the

mu lti-thr eaded portion s. This d ecou pling of synch ronization policies

in each layer enables non-reentrant functions to be used correctly,

with out requ iring ch an ges to exis ting code. t

Centralization. Inter-layer communication is localized at a s ingle

point becau se all interaction is mediated b y the qu eueing layer. The

queueing layer buffers messages passed between the other two

layers. Th is elimina tes th e complexity of locking an d ser ialization th at

would occur i f the synchronous and asynchronous task layers

accessed each other 's m emory directly.

However, th e Half-Sync/ Half-Asyn c patt ern also ha s th e followin g

liabilities :

A bou nd ary -cros s ing pena lty m ay be incu rred from synchronization,

data copying, an d con text switching overhea d. This overhea d typically

occurs when da ta is t ransferred be tween the synchronous and

asynchronous task layer via the queueing layer. In particular, most

operating system s tha t us e the Half-Sync/ Half-Async patt ern p lace

the queueing layer a t the boundary be tween the user- leve l and

kernel-level protection domains. A significant performance penalty

may be incurred when cross ing th is boundary . For example , the

socket layer in BSD UNIX accounts for a large percentage of the

overa ll TCP/ IP networkin g overh ead [HP91].

As y nch ron ou s I/ O for h igh er-level ta s k s is lack ing. Depending on the

design of system interfaces, it may not be possible for higher-level

tas ks to u ti lize low-level asynch ronou s I/ O devices. Thu s, th e system

I/ O s t ruc tu re ma y prevent app lica t ions from u s ing the hardware

efficiently, even if externa l devices s u pport asyn chr onou s overlap of

comp uta t ion and commu nica t ion.

7/31/2019 HS-HA

20/20

2 0


26.11.19 99 HS-HA.doc

See Also The Ha lf-Sync/ Half-Async pa ttern can be viewed a s a composite

pa t te rn tha t combines Reactor / Proactor pa t te rn s with the Act ive

Object patt ern . The s ynchr onou s ta sk layer can u se th e Active Object

pat tern (269 ). The Active Object p atter n decouples m ethod execut ion

from m ethod invocation to s implify synchr onized access to a s ha red

resou rce by meth ods invoked in different th reads of control.

The asynchronous task layer may use the Reactor pa t te rn (97) or

Proactor patter n (121) to demu ltiplex event s from mu ltiple I/ O

sources. The Reactor and Proactor patterns are responsible for

demultiplexing and dispatching event and completion handlers ,

respectively. Thes e patt ern can be u sed in conjun ction with th e Active

Object patter n to form th e Half-Sync/ Half-Async pa ttern .

Credits We would like to thank Lorrie Cranor and Paul McKenney for

comm ents a nd su ggestions for imp roving th is paper.

hs-ha

Documents