Real-Time Programming –

A Java-based approach
Klas Nilsson
Part 1 chapters, fall 2005
EDA040 @
Dept of Cop!ter "cience
#!nd $ni%ersit&
(his 'ork, 'hich sho!ld res!lt in a freel& a%aila)le )ook, doc!ents ho' to
carr& o!t safe
, fle*i)le
, porta)le
and free
pro,rain, of e)edded s&s-
tes, s!ch that the soft'are 'itho!t odifications can r!n on )oth sall
e)edded de%ices as 'ell as on standard .a%a platfors /.DK1.4.1 or later0.
(he approach is oti%ated )& and )ased on the follo'in, insi,hts1
• Efficient de%elopent of f!t!re soft'are 'ill increasin,l& )e ade for e-
)edded s&stes 'ith net'ork connections and co)ined real- tie and
desktop- like f!nctions. (hat re2!ires the safe, fle*i)le, and porta)le soft -
'are techni2!es.
• (he idea of 3'rite once r!n an&'here4 that 'as for!lated for 5nternet-
read& soft'are is hi,hl& desira)le for e)edded soft'are. (hat is, e)ed -
ded soft'are !st e*ist in porta)le for that s!pports deplo&ent into
specific confi,!rations accordin, to application needs.
• 5t is ost s!ita)le to !se an o)6ect- oriented and ind!striall& accepted lan -
,!a,e that f!lfills the re2!ireents on safet& and fle*i)ilit&. .a%a is the
ost a%aila)le and porta)le s!ch lan,!a,e, 'ith possi)ilities for a!to-
atic translation to the 7icrosoft .NE( platfor if needed.
• (he standard .a%a platfor does not s!pport real- tie e*ec!tion, )!t it
s!pports conc!rrenc& and real- tie properties are open to each iple -
entation. 8& pro%idin, r!n- tie sol!tions for real tie, to,ether 'ith
copilation to traditional )inar& code, .a%a- )ased real- tie 'o!ld )e %er&
• Each piece of soft'are !st )e 'ritten s!ch that it r!ns on )oth standard
desktop cop!ters s!ch as 9indo's and #in!*, as 'ell as on e*istin, and
f!t!re e)edded platfors. A co)ination of .a%a and C, s!pportin, li-
)raries, and !ltiple odels of e*ec!tion is then needed.
• Apart fro de%ice dri%ers that need to )e s&ste specific, soft'are needs
to )e 'ritten s!ch that it 'orks conc!rrentl& correctl& and 'ith appropri -
ate a'are tiin, on the desktop :", 'hile pro%idin, real- tie ,!arantees
'hen r!n on a real- tie :".
1 "oft'are coponents sta& in their so called sand)o*es; e*ec!tion cannot har
!nrelated data or code. <ere this is accoplished )& !sin, the .a%a language and
it=s )!ilt- in safet&.
2 E*ec!tion adopts to the properties of the !nderla&in, r!ntie s&ste; conc!rrenc&
correctness is aintained 'hile real- tie perforance %aries fro hard to soft in a
fle*i)le anner accordin, to the properties of the :", ana,ed )& s!pportin,
+ De%eloped applications r!n 'itho!t recopilation on an& t&pe of cop!ter to
'hich the .a%a platfor has )een ported, and 'ith recopilation on an& t&pe of
e)edded processor. A C copiler and a set of nati%e f!nctions is then needed for
s!ch e)edded processors.
4 "oft'are de%elopent, copilation, deplo&ent, and e*ec!tion sho!ld )e possi)le
'itho!t an& costs /ro&alties, fees for li)raries, etc.0 or dela&s /p!rchasin,, le,al
atters, etc.0 for licenses /doc!ents, don,les, etc.0; for st!dent !se and for a,ile
prod!ct de%elopent.
• >eal- tie re2!ireent s sho!ld )e e*pressed, and possi)le to e*press, in the soft -
'are. >eal- tie pro,rai n, is the =art= of ho' to do that. >eal- tie s&stes are
traditionall& )!ilt )& de%elopin, conc!rrent soft'are, 'hich is then deplo&ed on a
real- tie platfor. (he real- tie deands can then )e f!lfilled, )!t onl& 'ith e*-
tra en,ineerin, for each ne' t&pe of s&ste. (hat is in an& cases not an option,
d!e to arket opport!nities or since s&stes a& need to )e reconfi,!red ?on the
field? to !nforeseen confi,!rations.
• (he 'ide-spread !se of pro,raa)le de%ices, or de%ices incl!din, e)edded
soft'are that a& need fre2!ent c!stoi@ation, calls for 3technicall& ,enerall&
!sef!l4 soft'are tools
and platfors, and free soft'are. (he platfor !st per -
it specific applications )!ilt on top of it to )e proprietar& and closed, to protect
)!siness- critical kno'- ho' /soft'are patent do not 'ork0.
5n parallel 'ith this doc!ent, free soft'are tools are )ein, de%eloped and ade
a%aila)le on the 5nternet, )& o!r ,ro!p and d!e to other efforts. Coercial soft -
'are can then )e de%eloped for specific applications and s&stes, and since s!ch
soft'are is not 3technicall& ,enerall& !sef!l4 the& a& %er& 'ell )e proprietar&.
"till, the technolo,&, li)rar& and tools presented here a& )e !sed free of char,e
/e%en coerciall&0, )!t additions and chan,es !st reain free /BN$ #BP#0.
Note 1 (his doc!ent still contains aterial fro other so!rces 'itho!t proper ref-
erences; this 'ill )e taken care of )efore official release. Details of the licenses fro
"!n 7icros&stes are also !nder detailed re%ie'in,.
(o )e 'ritten /referrin, to the #(< research in ro)otics and e)edded real- tie
s&stes, and to the de%elopents for the EDA040 co!rse0.
(his section is s!)6ect to special conditions in the BN$ license ters.
A (hat in t!rn, as e*pressed )& >ichard "tallan /the fo!nder of BN$0, iplies that s!ch
soft'are /)!t not the applications !sin, it0 !st )e free.
Licenses and redistribut i on of copi es
(his doc!ent is /or 'ill )e0 released !nder the ters of BN$ CD#1
Copyright (c) 2005 Klas Nilsson
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts. A copy of the license is included in the section entitled "GNU
Free Documentation License".
(he BN$ Cree Doc!entat ion #icense is also a%aila)le at
Cor r!nnin, the proposed soft'are on ,eneral desktop or ser%er cop!ters, it
is ass!ed that the !ser has a properl& licensed .a%a2 platfor, 'hich is
a%aila)le for free do'nload fro "!n /6a%a.s!, 'here the "!n license
conditions also can )e fo!nd0 for ost coon t&pes of desktop cop!ters.
Cor e)edded or real- tie e*ec!tion on platfors, 'e propose and ass!e
the !se of the free BN$ Classpath /'''.,n!.or,Dsoft'areDclasspat h0 %ersion
of the standard li)raries. (o,ether 'ith BC. /,cc.,n!.or,D6a%a0 these li-
)raries can )e !sed for non- real- tie applications, 'hile 'e !se the BN$ li-
)raries /)!t 'ith BCC and not BC.0 and o!r o'n translater and r!ntie
s&ste for real- tie applications. 8e a'are of the Java trap e*plained in
Cree 8!t "hackled - (he .a%a (rap /'''.,n!.or,Dphilosoph&D6a%a- l0
Table of Contents
Chapt er 1 Introduct i on ............................................................................................ 3
1.1 Exampl e 1: he LE!"#$bric% machi ne ..............................................&
1.' Exampl e ': (an%$ account transact i ons ..............................................)
1.3 (oo% outli ne ................................................................................................... *
Chapt er ' +undament al s ......................................................................................... ,
'.1 -oft.are execut i on is performed se/uent i al l y ...............................,
'.' "ur physi cal .orld is parallel ................................................................0
'.3 Parall el computi n1 ......................................................................................2
'.& Concurrency ................................................................................................ 11
E%ent processin, ......................................................................................... 12
(ie and encaps!lation ............................................................................ 1+
Pro,rai n, of parallel se2!ences ........................................................14
'.) Interrupt s3 pre$ empti on3 and reentrance ....................................... 1)
:)tainin, the tie )ase ............................................................................ 1E
Pre- eption .................................................................................................. 1F
>eentrance ....................................................................................................1G
'.* 4odels of concurrent execut i on ......................................................... 12
C!ndaent al a)stractions ........................................................................20
Conc!rrenc& in .a%a .................................................................................. 2+
Processes and interr!pts ........................................................................... 24
'., 4ulti$ process pro1rammi n1 ................................................................. ')
'.0 "b5ect interacti on and encapsul at i on ..............................................'*
'.2 -oft.are issues ...........................................................................................'0
Chapt er 3 4ulti$ hreaded Pro1rammi n1 ...................................................... '2
3.1 hreads .......................................................................................................... 36
(hread creation ........................................................................................... +0
(ie ............................................................................................................... +1
"leepin, .........................................................................................................++
>ace conditions ............................................................................................ +5
"ched!lin, H Priorities .............................................................................. +E
(hread interr!ption and terination .................................................... +G
(he (hread class ......................................................................................... 41
3.' 7esources and mutual excl usi on 8 -emaphores .......................... &'
"eaphore ethods ................................................................................... 4+
$sin, seaphores .......................................................................................45
(he seaphores packa,e ......................................................................... 4I
3.3 "b5ects pro9i di n1 mutual exclusi on 8 4onitors .......................... )3
"&nchroni@ed ................................................................................................5+
Conditions H 'ait and notif&.................................................................... E1
7ore on onitor pro,rai n, ................................................................EI
3.& 4essa1e$ based communi cati on 8 4ailboxes ..................... ,'
7ore on o)6ect interaction ............................................................ F+
E%ents and )!ffers ......................................................................... F+
(hreads and e%ent- )ased co!nication ................................ G2
Introducti on
Chapter 15nt rod!ction
Goal: To understand what this book is about.
op!ters, s!ch as icroprocessors, are ore and ore often e)edded in prod-
!cts that the !ser does not percei%e as cop!ters. (his is the case for )oth con-
s!er electronics /&o!r CD pla&er, o)ile phone, etc.0, hoe s!pplies /&o!r icro-
'a%e o%en, 'ashin, achine, etc.0, %ehicles /the en,ine control in &o!r car, airplane
fl&-)&-'ire control, etc.0, )!ildin, a!toation /ele%ator control, teperat !re control,
etc.0, as 'ell as for ind!strial e2!ipent. 9e 'ant these thin,s to )e afforda)le, and
'e 'ant to )e a)le to tr!st their operation, in partic!lar 'hen o!r life depends on
the. Additionall&, in soe cases, 'e 'ant to )e a)le to reconfi,!re, !p,rade, or
e%en pro,ra the, possi)l& )& do'nloadin, soft'are coponents fro a tr!sted
s!pplier %ia the 5nternet.
7ost people think of a cop!ter as the desktop t&pe of cop!ter /'ith ke&)oard and
displa&0, )!t the n!)er of e)edded cop!ters is )i,,er than the n!)er of all
other t&pes of cop!ters, and the difference is increasin,. 7oreo%er, the %ariet& of
t&pes of processors and operatin, s&stes is !ch lar,er in the e)edded 'orld,
'hich incl!des the desktop t&pes and an& others. >easons for this %ariet& incl!de
optii@ation to red!ce the prod!ct price and inii@ation of ener,& /fro )atteries0
De%elopent of e)edded soft'are has for soe &ears ainl& )een carried o!t )&
hard'are- a'are pro,rai n, !sin, the C-lan,!a,e, and in soe cases e%en in as -
se)l& lan,!a,es. (his 'orks 'ell in siple cases 'hen the application deands
and the hard'are are kno'n at desi,n tie, and the si@e of the /staticall& defined0
soft'are is sall. 9hen applications increase in si@e and !st )e rapidl& de%eloped
/tie to arket0, and perhaps need to )e on-line !p,radea)le, ore pro,rain,
s!pport is needed. 5n partic!lar, for critical applicati ons /safet& critical as in an
airplane, ission critical as in spaceDilitar&Dn!clear tasks, econoicall& critical if
the s!r%i%al of the copan& depends on the relia)ilit& of the cop!ter s&ste, etc.0
special eas!res !st )e taken to liit the possi)le /fa!lt&0 infl!ences of one soft -
'are f!nction on another part of the s&ste. (herefore, 'e ha%e to a)andon pro-
,rain, in C or CJJ for lar,eDcople* s&stes. 5nstead, 'e ha%e to )ase the core
de%elopent on a ore scala)le lan,!a,e /and r!n- tie s&ste0 that pre%ents di-
rect access to eor&, for instance %ia pointers. .a%a /and partl& CK0 is s!ch a lan -
,!a,e. "till, pro,rain, in C is appropriate for de%ice dri%ers, 'hich do need to di-
rectl& access the hard'are. Cor siilar reasons of scala)ilit&, 7icrosoft had to ,o
fro their 9in+2J7CC CDCJJ-oriented standard to the ?dot-net? platfor 'ith CK
in order to sta& copetiti%e in the lon, r!n. <ere, 'e 'ill ,o soe steps f!rther,
considerin, also sall e)edded s&stes and se%ere tiin, deands.
.a%a does not sol%e all pro)les, and it is not the )est possi)le sol!tion, )!t it has
the 2!alities that 'e need to )!ild hi,her- le%el f!nctionalit& and tools. C!rtherore,
it is )ased on open standards and has the desired s!pport and /free0 a%aila)ilit&.
<o'e%er, there is a coon isconception in )oth ind!str& and acadeia1 (he .a%a
200E- 01-11 15105 L 3
Chapter 1 Introduction
lan,!a,e is not s!ita)le for real- tie pro,rain,. 5n the se2!el it 'ill )e e*-
plained 'h& this is not tr!e, and ho' it can and sho!ld )e done.
Bi%en the nice properties of the .a%a pro,rain, lan,!a,e, s!ch as sec!rit& and
platfor independence, 'e 'ant to e*ploit the ad%anta,es for de%elopent of real-
tie control soft'are, e%en for s&stes s!)6ect to se%ere deands on perforance
and predicta)ilit&. E%en tho!,h .a%a fro the )e,innin, 'as intended for pro,ra-
in, e)edded control de%ices, soe ind!st riall& iportant control aspects 'ere
ne%er dealt 'ith, and the a6or de%elopent and s!ccess has )een 'ithin 5nternet
pro,rai n, of interacti%e applications s!ch as applets.
9e 'ill approach the real- tie iss!e )& first !sin, ordinar& 'e)-pro,rain, and
conc!rrenc& techni2!es, 'hich 'ill re%eal a fe' deficiencies of the standard .a%a
platfor. A real- tie packa,e /class li)rar&0 and a fe' r!n- tie e*tensions 'ill )e
presented. (he !sa,e of these additions to create hi,h perforance real- tie control
soft'are is then descri)ed in a real- tie pro,rai n, chapter 'hich is central the
topic of this )ook. (he reader sho!ld then ,ain additional !nderstandin, and pro-
,rain, skill )& st!d&in, the reainin, chapters a)o!t sched!lin,, processes, and
(o ill!strate the notions of conc!rrenc&, real- tie, and control /in the order en -
tioned0 t'o siple application e*aples no' follo's. 5n the li,ht of these e*aples,
a ore detailed o!tline of the )ook concl!des the introd!ction.
1.1Example 1: The LEGO
-brick machine
Cop!ter control of a achine for an!fact!rin, #EB:- )ricks, as depicted in Ci,-
!re 1-1, iplies t'o re2!ireents on the soft'are1
& >eal- (ie Pro,rain, H a .a%a- )ased approach
Figure 1-1 Schematic figure of a machine for manufacturing of LEGO bricks
Example 1: The LEGO®-brick machine
1. (he teperat !re of the plastic aterial sho!ld )e eas!red and controlled peri -
odicall& to prepare the aterial for castin, 'ith the proper 2!alit&.
2. (he piston of the c&linder sho!ld )e controlled se2!entiall& to act!all& perfor
the castin,.
Note that the tasks accordin, to ites 1 and 2 need to )e handled conc!rrentl&, and
each task has to )e carried o!t in real tie. :ther'ise the achine 'ill not 'ork.
5te 1 is a siple teperat !re re,!lator. "ince readin, the eas!red %al!e /temp0
and cop!tin, the control si,nal /doHeat0 takes soe tie, s!ch feed)ack control,
'hen done in soft'are, )& necessit& has to )e carried o!t periodicall&. 5n each period
/also called a saple0, the controlled s&ste in eas!red /sampled 0, and the co-
p!ted control si,nal is sent to the controlled s&ste. Cor reasons of control perfor -
ance, the tie )et'een each saple sho!ld not )e too lon,. Cor cop!tin, /CP$-
load0 reasons, 'e 'ant to ha%e as lon, saplin, period as possi)le. <ence, a trade -
off )et'een control and cop!tin, efficienc& has to )e ade. (his t&pe of control is
time driven since it is r!n 'ith respect to /real0 tie 'itho!t 'aitin, for
5te 2 is an e*aple of se2!encin, control, 'hich is event driven /e*ec!tion ad-
%ances 'hen certain e%ents occ!rs and arri%es to the soft'are0; 'ritin, this as a pe-
riodic controller 'o!ld ipl& !nnecessar& saplin, and e%al!ation of the state of
the application. :n the other hand, if e*ec!tion onl& ad%ances on incoin, e%ents,
ho' sho!ld then the teperat!re control )e carried o!t /in the sae pro,ra0M
(he reader co!ld tr& to 'rite one se2!enti al pro,ra perforin, )oth these tasks.
Note that neither the teperat !re control nor the se2!encin, control a& )e de-
la&ed d!e to the d&naics of the other part. C!rtherore, ass!e it sho!ld )e si-
ple /no repro,rai n,, onl& alterin, a data %al!e0 to chan,e the saplin, period of
the teperat !re control.
A )etter 'a& is to 'rite t'o pieces of pro,ra, for instance t'o classes that handle
the t'o control tasks. <o' sho!ld that )e done, and 'hat re2!ireents does that
p!t on the pro,rai n, and r!n- tie s&steM
1.2 Example 2: Bank-account transactions
A failiar e*aple of conc!rrentl& occ!rrin, actions on the sae data ite, is )ank
acco!nt transactions. Ass!e that there are t'o transactions that are to )e carried
o!t at a)o!t the sae tie. :ne of the, 'hich 'e call A, consists of takin, o!t
N1000 fro the acco!nt %ia a one& achine. (he other transaction, 'hich 'e call
8, is to add a salar& of N10000 to the acco!nt. Dependin, on the act!al tiin,, and
dependin, on ho' the )ank cop!ter perfors the transactions, 'e o)tain different
cases. 5f one transaction is perfored )efore the other, 'e ha%e one of the t'o cases
sho'n in Ci,!re 1-2. Each se2!ence of operations e*presses the 'a& the cop!ter at
the )ank perfors the re2!ested transactions.
200E-01-11 15105 © )
Chapter 1 Introduction
Accordin, to proper soft'are en,ineerin, practice, the t'o se2!ences are prefera)l&
e*pressed separatel& as descri)ed in the pre%io!s e*aple. C!rtherore, ass!e
that the r!n- tie s&ste of o!r cop!ter is capa)le of interlea%in, the t'o se-
2!ences in s!ch a 'a& that the& appear to )e done si!ltaneo!sl&. "ince the inter -
lea%in, is not specified in the indi%id!al pro,ras as sho'n in the fi,!re, it co!ld
res!lt in an& order of operations dependin, on the !nderl&in, s&ste, and it co!ld
possi)l& )e different fro tie to tie. Cor instance, 'e a& for the a)o%e transac -
tions o)tain interlea%in,s accordin, to Ci,!re 1-+. E%en if a!toatic interlea%in, of
code se2!ences often is desired to handle se%eral tasks in parallel, 'e see that 'e
!st )e a)le to specif& a se2!ence of operations to )e perfored 'itho!t )ein, inter -
r!pted )& other se2!ences anip!latin, the sae /shared0 data. 9e shall learn se%-
eral 'a&s to sol%e this t&pe of pro)le.
1.3 Book outline
5n the ne*t chapter, 'e 'ill ,o tho!,h the f!ndaent als of pro,ra e*ec!tion 'ith
special interest in the conc!rrenc& iss!e and in the properties of the .a%a lan,!a,e.
5n Chapter +, the .a%a lan,!a,e is !sed for sol%in, conc!rrent pro,rai n, pro)-
les. Doin, that, ho'e%er, also re%eals soe deficiencies of the standard .a%a plat -
for and classes. (herefore, in Chapter 4, additional classes s!pportin, real- tie
pro,rai n, 'ill )e presented. (hen in Chapter 5, 'e 'ill learn ho' to do real-
tie pro,rain, !sin, the classes fro Chapter 4.
* >eal- (ie Pro,rain, H a .a%a- )ased approach
Figure 1-3 The two bank account transactions interleaved in two different ways. ith
Timing !" the resulting amount is #!$%%%" but the result is #&%%% in the
timing ' case. (ence" the final results are wrong and depend on time"
which is clearly not acceptable.
imin1 1:
A1 >ead 5000
81 >ead 5000
A1 Ao!nt O 5000 - 1000
81 Ao!nt O 5000 J 10000
A1 9rite 4000
81 9rite 15000
imin1 ':
A1 >ead 5000
81 >ead 5000
81 Ao!nt O 5000 J 10000
81 9rite 15000
A1 Ao!nt O 5000 - 1000
A1 9rite 4000
Figure 1-2 Two bank account transactions done in two different orders. )n both cases"
the original amount was #$%%% and the resulting amount is #!&%%% as e*+
Case 1: :ithdra. first
A1 >ead 5000
A1 Ao!nt O 5000 - 1000
A1 9rite 4000
81 >ead 4000
81 Ao!nt O 4000 J 10000
81 9rite 14000
Case ': -alary first
81 >ead 5000
81 Ao!nt O 5000 J 10000
81 9rite 15000
A1 >ead 15000
A1 Ao!nt O 15000 - 1000
A1 9rite 14000
+undament al s
Chapter 2C!ndaentals
Goal: ,eview of basic properties of software e*ecution as a preparation
for dealing with concurrency and real+time issues.
lread& ha%in, soe pro,rain, e*perience eans that &o!, dear reader,
ha%e a lot of kno'led,e a)o!t ho' a cop!ter interprets or e*ec!tes a co-
p!ter pro,ra. 9hen &o! kno' it, it is all nat!ral, and ost pro,raers are not
a'are of the insi,hts the& ha%e ,ained. 9e are no' a)o!t to 'rite pro,ras that )e-
ha%e conc!rrentl& e%en if 'e onl& ha%e one processor. 8efore doin, so, it co!ld )e a
,ood idea to take a step )ack and re%ie' the )asic properties of pro,ra e*ec!tion.
(his is the first thin, that 'ill )e done in this chapter. (hen, different notions of
conc!rrenc& in hard'are and soft'are 'ill )e treated. Cinall&, 'e state the d!ties of
the soft'are s&stes 'e are a)o!t to de%elop.
(he ea,er and e*perienced pro,raer a& skip this chapter, )!t )e'are, &o! a&
)e a %er& skilled pro,raer 'itho!t ha%in, the profo!nd !nderst andin, &o! think
&o! ha%e.
2.1 Software execution is performed sequentially
(o recall the se2!ential nat!re of pro,ra e*e-
c!tion, ass!e &o! 'rite an ordinar& pro,ra
to )e r!n on an ordinar& cop!ter ha%in, one
processor /CP$0. A piece of the code a& look as
sho'n in Ci,!re 2.1. 9hat %al!e 'ill * ha%e
after lea%in, the loopM
Po! kno' that the res!ltin, %al!e of * 'ill )e
one. (he no%ice ans'erin, @ero )elie%es that the
loop-condition is contin!o!sl& e%al!ated in par -
allel 'ith e%al!ation of the e*pressions in the
loop. (h!s, the fact that the cop!ter treats o!r instr!ctions se2!entiall& one after
another cannot )e considered nat!ral to all of !s; soe of !s ha%e 6!st learned that
this is the 'a& it 'orks. Act!all&, it is a se%ere restriction that onl& one thin, at a
tie can )e done. E%en if cop!ters toda& are cop!tin, 2!ickl& eno!,h to do the
cop!tations re2!ired )& a parallel en%ironent /like o!r real 'orld0.
"o, 'hen learnin, to pro,ra, 'e are first forced into the Qnarro' alle&R of se2!en -
tial e*ec!tion. Copare this 'ith hard'are desi,n 'here each si,nal or inforation
flo' !s!all& is taken care of )& dedicated coponents ens!rin, contin!o!s and
tiel& operation. 8!t for reasons of cost and fle*i)ilit&, 'e cannot ipleent
e%er&thin, in hard'are, so the pro)le that 'e are facin, no' is that the se2!en -
tial soft'are e*ec!tion odel does not fit the inherentl& parallel pro)les 'e 'ant
to sol%e. E%en 'hen sol%in, parallel pro)les, ho'e%er, soe thin,s are still se-
200E- 01-11 15105 L ,
int x = 2;
while (x>1) {
if (x==10) x = 0;
/* What is x now? */
+i1ure '$1 7ade- !p code, tri%ial to
an& pro,raer )!t an& )e,inners
act!all& ,i%e the 'ron, ans'er 0.
Chapter 2 Fundamentals
2!ential to their nat!re /like a se2!ence of control actions to )e carried o!t in the
correct order0. (hen, for s!ch parts of the pro,ra, the se2!ential e*ec!tion of soft -
'are 'ill )e of ,reat con%enience.
2.2 Our physical world is parallel
(he o)6ect oriented pro,rai n, /::P0 paradi,, 'hich 'e 'ant to !se for e)ed -
ded pro,rain,, is )ased on creatin, soft'are entities odellin, o!r en%ironent.
C!rtherore, since 'e ai at cop!ter control of ph&sical de%ices, soe tho!,hts
a)o!t the en%ironent to )e controlled a& )e appropriate
As 'e all kno', o!r ph&sical 'orld is inherentl& parallel. 7atheaticall&, 'e need
sets of co!pled differential e2!ations to descri)e it. Coparin, s!ch atheatical
e*pressions 'ith the e*pressions fo!nd in pro,rai n, lan,!a,es s!ch as .a%a,
the& are not at all e*pressin, the sae thin,. 8asicall&, this is related to another )e-
,inners pro)le in pro,rai n,; the notion of e2!alit&. 9hen an atheatical e*-
pression states that *O&J2, that is an e2!alit& 'hich sho!ld hold for 'hate%er %al!e
* /or &0 has. 9hen 'e in a .a%a pro,ra 'rite *O&J2, 'e instr!ct the cop!ter to
take the %ale of &, add 2, and to store that in *. 5f 'e in .a%a 'rite *OO&J2, 'e test if
the %al!e of * e2!als &J2. (he atheatical e2!alit& cannot )e directl& e*pressed in
.a%a /or in an& other 'idel& !sed pro,rai n, lan,!a,e like C, CJJ, etc.0. A,ain,
cop!ters operate se2!ential fro a pro,raers point of %ie'.
Cor a sin,le /scalar0 differential e2!ation, 'e then ha%e an e%en harder t&pe of
e2!alit&. Apart fro the pre%io!sl& entioned pro)le, 'e ha%e to cop!te deri%at -
i%es of %aria)les /representin, ph&sical states0 and then 'e also ,et tr!ncation and
2!antification effects d!e to the )inar& representation of data 'ith finite
'ordlen,th. (herefore, 'e can onl& 'ork 'ith appro*iations of the real 'orld o)-
6ect, e%en if its properties 'o!ld )e kno'n e*actl&.
Cor a set of co!pled differential e2!ations, odellin, o!r real- 'orld o)6ects, the se-
2!encin, effect is an e%en )i,,er pro)le since all e2!ations are to hold in parallel.
Additionall&, state chan,es a& occ!r at discrete ties 'hich cannot )e e*actl& rep-
resented, and o!r odels a& incl!de lo,ical relations. (o o%ercoe these pro)les,
the follo'in, techni2!es are !sed 'ithin s&stes en,ineerin,1
1. Cor less cople* d&naics, e2!ations a& )e sol%ed and onl& the e*plicit sol!tion
need to )e ipleented. Cor instance, a real- tie cop!ter ,ae for pla&in,
3pin)all4 incl!des si!lation of the )all d&naics, 'hich can )e e*pressed as a
siple t&pe of n!eric inte,ration.
2. Cor s&stes 'ith lo' deands on acc!rac& or perforance, 'e a& appro*iate
or e%en oit the odel e2!ations. Cor instance, for soft-stop control of ele%ator
otions 'e a& !se an!all&- t!ned open- loop control 'itho!t an& internal od-
el. (his is opposed to optial perforance ro)ot otions 'hich re2!ire e*tensi%e
1 (his section /2.20 ais at deeper !nderstandin, or 'ider perspecti%es, )!t can )e skipped
)& the reader onl& carin, a)o!t practical pro,rain, iss!es.
0 >eal- (ie Pro,rain, H a .a%a- )ased approach
Our physical world is parallel
e%al!ation of otion d&naics.
+. 9e a& !se special p!rpose lan,!a,es and e*ec!tion s&stes that transfors de-
clarati%e descriptions to cop!ta)le e*pressions, i.e., a co)ination of soft'are
technolo,& and n!erical anal&sis. Cor instance, it is 'ell kno'n 'ithin the soft -
'are oriented part of the control co!nit& that o)6ect oriented odels of d&-
naic properties re2!ires declarati%e lan,!a,es s!ch as 7odelica. Another e*-
aple is that certain t&pes of lo,ical relations a& )e con%enientl& e*pressed in
(he cop!tational diffic!lties are taken care of at Qs&ste desi,n tieR, 'hich
eans that 'e !se hi,h perforance 'orkst ations to anal&se, si!late, and to de-
terine a control al,orith that is siple to cop!te in the e)edded s&ste. Cor
instance, )ased on the e2!ations and a d&naic odel of a s&ste /like d&naic
properties of a %ehicle0 'e a& !se si!lation tools to cop!te the )eha%io!r /like
rotation, position and %elocit&0 'hen certain actions are applied /like speed and
steerin, 'heel coands0, and soe control desi,n tool help !s deterine a control
la' e*pression 'hich can easil& )e ipleented and cop!ted in the e)edded
(he concl!sion fro this section is that o!r real ph&sical 'orld can )e 2!ite tro!)le -
soe fro a pro,rain, point of %ie'. (herefore, 'e sho!ld not appl& o)6ect ori -
entation and iperati%e lan,!a,es /s!ch as .a%a0 o!tside their concept!al liits,
and 'e sho!ld desi,n o!r s&stes so that al,orithic parts /possi)l& needin, spe-
cial treat ent as entioned0 are encaps!lated in classes in s!ch a 'a& that the&
can )e de%eloped separatel&. And fort!natel&, that separate treat ent can !s!all&
)e carried o!t at desi,n tie.
9e are then left 'ith the !ch sipler task of standard conc!rrent and real- tie
pro,rai n, 'hich is the topic of this )ook. 5n other 'ords, if 'e e*cl!de ad%anced
s&stes like certain t&pes of a!tonoo!s %ehicles and self-learnin, ro)ots, the par -
allelit& of the ph&sical 'orld is not a pro)le 'hen pro,rai n, e)edded s&stes
since 'e onl& co!nicate 'ith the en%ironent %ia a finite n!)er of inp!t- o!t -
p!t /5:0 connections 'ith discrete /liited ADD and DDA resol!tion0 %al!es and in
discrete tie /sapled 'hen the 5: de%ice dri%er is r!n0.
2.3 Parallel computing
(o eet the needs of hi,h- end cop!tin,, cop!ter hard'are de%elopent contin! -
o!sl& tries to ipro%e cop!tin, perforance. :ne pop!lar research approach for
the last t'ent& &ears has then )een to )!ild parallel cop!ters. (hat is, cop!ters
that contain an& processors 'orkin, in parallel. (oda&, late nineties, parallel co-
p!ters 'ith !p to E4 processors /CP$s0 of the sae t&pe sharin, a coon eor&
has ade it to the arket. (hen, 'hat are the iplications for conc!rrent pro,ra -
in, of e)edded s&stesMCirst, 'e sho!ld kno' that the ainstrea ind!strial
de%elopent of e)edded cop!ters is )ased on either sin,le CP$s, or !ltiple
200E-01-11 15105 © 2
Chapter 2 Fundamentals
CP$s that are separatel& pro,raed )eca!se the& contain different /loosel& con-
nected0 soft'are od!les. 7odern CP$s are po'erf!l eno!,h for at least specific
and encaps!lated parts of the soft'are f!nctions. <ence, pro,rain, is still car -
ried o!t on a sin,le CP$ )asis, possi)l& !sin, e*plicit interfaces )et'een !ltiple
• (he parallellit& of real- 'orld odels, as descri)ed in pre%io!s section, sho's !p
in technical cop!tin,. "oe t&pes of pro)les can )e decoposed into cop!ta -
tions that can )e done in parallel 'ith each other. <o'e%er, this is onl& 'orth -
'hile for special pro)les, and then ainl& d!rin, s&ste desi,n. (here are no
indications that parallel cop!ters re2!irin, special pro,rai n, techni2!es
'ill )e 'idel& !sed for e)edded cop!tin,. E*ceptions a& )e applications like
radar echo processin, and cop!ter %ision. "!ch inherentl& parallel applications
are iportant and deandin,, )!t it is o!tside the scope of this )ook since it e-
plo&s fe' pro,raers.
• (he ordinar& se2!ential pro,rai n, odel is so esta)lished that cop!ter
%endors ha%e to sta& 'ith it. (herefore, the parallelit& of the hard'are is taken
care of )& special copilers and r!n- tie s&stes, still aint ainin, an !n -
chan,ed %ie' to the pro,raer. (here is e%en a trend that the parallelit& is
f!ll& taken care of )& the hard'are. <ard'are de%elopers talk a)o!t the 3se-
2!ence control )arrier4 'hich eans that the hard'are parallelit& a& not %iol-
ate the se2!encin, propert& of the soft'are e*ec!tion as descri)ed in "ection 2.1.
(h!s, e%en if 'e sho!ld !se a PC r!nnin, 9indo's on fo!r CP$s, 'e do not ha%e
to care a)o!t that 'hen 'ritin, o!r soft'are.
5n concl!sion, the se2!ential e*ec!tion odel descri)ed earlier is alost al'a&s %al -
id e%en 'hen parallel cop!ters are !sed. Coents a)o!t soft'are interfaces
)et'een different processors 'ill )e ,i%en in a fe' places in this )ook, )!t ,enerall&
'e sho!ld think in ters of !sin, a sin,le CP$.
16 >eal- (ie Pro,rain, H a .a%a- )ased approach
2.4 Concurrency
:!r soft'are applications interact 'ith !sers and e*ternal e2!ipent %ia inp!tDo!t -
p!t interfaces, ,enerall& called the 5:. (he cop!ter recei%es inp!t data conc!r -
rentl& fro sensors and fro !ser inp!t de%ices like ke&)oard, o!se, and icro-
phone, as depicted in Ci,!re 2-+. Cro the !ser 'e talk a)o!t inp!t e%ents, and
fro the sensors 'e talk a)o!t saples. 8oth inp!t e%ents and saples reach o!r
pro,ra in for of soe kind of data entit& or record. Cor a o!se click, for e*-
aple, the e%ent t&picall& contains the hori@ontal and %ertical coordinates on the
screen and the tie 'hen the click occ!rred. "apled ph&sical %al!es for feed)ack
control are !s!all& o)tained %ia dedicated 5: interfaces 'ith 'ell defined tiin,
and )!fferin,; e*tra dela&s in ters of !nforeseen )!fferin, co!ld ca!se the feed-
)ack control to )e !nsta)le. (here is no clear distinction )et'een the t'o loops in
Ci,!re 2-+ /for instance real- tie ,aes onl& ha%e one t&pe of loop and ph&sics is
directl& a%aila)le to the !serDdri%er in %ehicles0, )!t it is norall& ,ood to )e a'are
of it for en,ineerin, p!rposes.
Ass!e 'e onl& kno' ordinar& se2!ential pro,rai n,. E%en if 'e !se o)6ect ori -
ented desi,n and pro,rain,, 'ith classes and o)6ects defined accordin, to real-
'orld o)6ects, ethods are se2!ential and called se2!enti all& so 'e still ha%e the
sae sit!ation as coented in the )e,innin, of this chapter. Ph&sicall&, all inp!t
200E-01-11 15105 © 11
Figure 2-2 )nput in terms of user commands - actions and sampled measurements
must be concurrently and timely handled by our software. .,e/computed
outputs for user perception and control actuation form two feedback loops.
"oft 'ar e
applicat ion
0ontrolled system
Ph&sical d&naics
1 s e r i n t e r a c t i o n l o o p
2 e e d b a c k c o n t r o l l o o p
Chapter 2 Fundamentals
a& occ!r in parallel, and 'e can ,enerall& not ake an& ass!ptions a)o!t the
res!ltin, order of the data that is inp!t to o!r pro,ra. (he pro)le 'ith p!re se-
2!ential pro,rain, is that the pro,raer !st define in 'hat order cop!tin,
sho!ld )e done, )!t it is not kno'n in 'hat order inp!t data 'ill arri%e, or the pro-
,ra has to 'aste CP$ tie on e*cessi%e pollin, and e%al!ation of conditions that
a& infl!ence the o!tp!t.
Cor e*aple, reconsider the #EB:- )rick achine. Ass!e 'e ha%e ipleented
the control pro,ra as one loop in 'hich all 5: and control is carried o!t se2!en -
tiall&. (hen consider 'hat the chan,es 'ill )e if, sa&, the saplin, fre2!enc& of the
teperat !re control is s!)stantiall& chan,ed. "ince the pro,raer has to an! -
all& do the interlea%in, of the code for the different acti%ities, chan,es in conc!r -
renc& or tiin, ha%e se%ere ipact on the so!rce code. As entioned, a ore at -
tracti%e approach 'o!ld )e to ha%e the teperat !re control e*pressed 'ell separ -
ated fro the se2!encin, control of the piston, 'hich also 'o!ld )e nat!ral fro an
o)6ect-oriented pro,rai n, point of %ie'. (he pro)le is, ho'e%er, that o)6ect ori -
entation )& itself does not s!pport conc!rre nc&.
(he sae t&pe of pro)les sho' !p in interacti%e soft'are. Cor e*aple, an applet
containin, a 'e) aniation and a )!tton to select if the aniation sho!ld )e pla&ed
for'ard or )ack'ard is for the p!rposes of this treat ent e2!i%alent to the #EB:-
)rick achine. Aniation 'ith a certain frae rate corresponds to the periodic te-
perat!re control, and handlin, of the p!sh )!tton corresponds to handlin, the posi -
tion sensor. Cor the p!rposes of this )ook, ho'e%er, 'e 'ill ainl& consider control
applications 'hich are s!)6ect to ore se%ere deands in later chapters. 9hen 'e
kno' ho' to cope 'ith )oth conc!rrenc& and real tie for control applications, 'e
'ill also )e a)le to handle /the sipler0 interacti%e s&stes.
8ehind the ter concurrent programmi ng is the fact that o!r soft'are has to handle
conc!rrentl& occ!rrin, e*ternal e%ents. 8!t )efore akin, a definition of the ter,
let !s re%ie' soe alternati%e approaches to handle the sit!ation.
Event processing
5n the siplest case, each inp!t e%ent can )e iediatel& and f!ll& handled )efore
an& follo'in, e%ents !st )e taken care of. (hen o!r pro,ra a& consist of onl&
data str!ct!res, so called event handlers 'hich perfor the processin, of each e%ent,
and a so called dispatcher that calls the appropriate e%ent handler for each incoin,
e%ent. (here 'o!ld, for e*aple, )e one e%ent handler takin, care of o!se clicks
'hich then 'o!ld res!lt in chan,es of the data str!ct!res, !s!all& reflected on the
screen. (he dispatcher is called in a siple loop 'hich there)& is Qdri%in,R the applic-
(he loop retrie%in, the e%ents /or essa,es0 and callin, the handlers is /in 7icrosoft
ters0 called the essa,e p!p. 9hen pro,rai n, !ser interfaces !sin, pop!lar
class li)raries like 7CC /7icrosoft Co!ndation Classes0, A9( /the .a%a- )ased A)-
stract 9indo' (oolkit pro%idin, an interface to nati%e ,raphics and 'indo' s&s-
1' >eal- (ie Pro,rain, H a .a%a- )ased approach
tes0, or .CC /.a%a Co!ndation Classes, no' kno'n as "'in,0, the essa,e p!p
is hidden inside the class li)rar&. Application pro,rain, then eans 'ritin, the
e%ent handlersDlisteners and re,isterin, the to the s&ste.
E%ent processin, is eas& to pro,ra )!t in ost applications, and partic!larl& in
control applications like o!r #EB:- achine, this e*ec!tion odel alone is not s!ffi -
cient. (he reasons are1
• :!r sin,le control loop 'ill cons!e all a%aila)le CP$ tie for the s!ccessi%e
testin, /called pollin,, or )!s& 'ait if nothin, else is )ein, done0. (his is 'aste of
processin, po'er 'hich pre%ents the cop!ter fro si!ltaneo!sl& )ein, !sed
for other tasks.
• 7ost control f!nctions, )!t not this one, need a notion of tie to 'ork correctl&.
Cor e*aple, if there 'o!ld ha%e )een dist!r)ances on o!r eas!reent si,nal,
or if 'e 'o!ld need to predict the teperat !re soe tie ahead, saplin, and
cop!tin, 'o!ld re2!ire proper and kno'n tiin,
(he strai,htfor'ard sol!tion no' is to con%ert o!r control f!nction into a for s!it -
a)le for e%ent processin,, and to ha%e control e%ents periodicall& ,enerated 'ith a
certain tie period. (his is act!all& a !sef!l ethod for %er& sall soft'are s&s -
tes, like soft'are for so called icrocontrollers. Cor o!r e*aple application this
eans that 'e sho!ld1
1. >eo%e the loop stateent aro!nd the control al,orith and the 'aitin, for ne*t
saple to sipl& ,et a f!nction cop!tin, one ne' control o!tp!t )ased on one
sin,le inp!t e%ent.
2. Connect soe e*ternal tier hard'are ,eneratin, periodic tie e%ents to the
pro,ra. (his is )!ilt into so called icrocontroller chips, and a%aila)le on /al -
ost0 an& cop!ter )oard. (he tier sho!ld )e set !p to e*pire often eno!,h to
o)tain ,ood control, )!t seldo eno!,h not to 'aste CP$ tie. /(o find an appro-
priate %al!e is a control en,ineerin, task 'hich is not co%ered.0
<o'e%er, s!ch an interr!ptDe%ent- dri%en techni2!e does not scale !p %er& 'ell. 5a -
,ine a control cop!ter handlin, an& control loops 'ith different saplin, peri -
ods, that 'o!ld re2!ire non- standard tier hard'are, and the dispatchin, of tier
e%ents 'o!ld )e tro!)lesoe. C!rther disad%ant a,es 'ill )e entioned )elo'. (h!s,
e%ent processin, as a ,eneral echanis is ainl& !sef!l 'hen de%elopin, !ser in-
terfaces or cop!tin, f!nctions that can r!n to copletion and ret!rn 'hene%er
tri,,ered /)& tie, o!se clicks, etc.0. <ere 'e also need other ore po'erf!l con-
Time and encapsulation
(he ain liitation 'ith p!rel& e%ent- dri%en soft'are is that the processin, !st
)e copleted iediatel& not to dela& processin, of the s!)se2!ent e%ents. 9hen
the re2!ired cop!tin, takes to lon, tie to coplete, 'e need soe eans to
sched!le to 'ork to )e done. Cor instance, the !ser p!shin, a )!tton in a 'e)-)ased
200E-01-11 15105 © 13
Chapter 2 Fundamentals
application a& res!lts in a re2!est for inforation to )e do'nloaded %ia 5nternet.
Clearl&, 'e need soe eans to let the e%ent handler start /or ,i%e data to0 an on,o-
in, acti%it& takin, care of the loadin,. (hat acti%it& then needs to )e interr!pti)le
)& other e%ents, and possi)l& )& ore iportant on,oin, acti%ities iss!ed )& those
Another reason that 'e need on,oin,, and interr!pti)le, acti%ities is soft'are 2!al -
it&. 5t is f!ndaent al )oth 'ithin ::P and pro,rain, in ,eneral to keep infor-
ation locall& 'hene%er possi)le, and to let the pro,ra clearl& e*press the task to )e
perfored. Consider a control loop s!ch as the teperat !re control of the #EB:-
)rick achine. P!ttin, the control stateents /incl!din, tiin, re2!ireent s0 in a
loop 'ithin a ethod of the control o)6ect is clearl& )etter than ha%in, the tiin, re-
2!ireents re,istered in one part of the pro,ra and the control actions coded in
another part. "o a,ain, 'e 'ant to )e a)le to e*press o!r cop!tations and control
al,oriths in an o)6ect-oriented anner as 'e are !sed to, and ha%e a r!n- tie s&s -
te that takes care of sched!lin, the different acti%ities.
5n .a%a applets the e%ent handlin, is perfored in f!nctions like action and
handleEvent, 'hereas on,oin, acti%ities are /or at least sho!ld )e0 done in f!nctions
like r!n. 8!t )efore 'e learn ho' to desi,n and pro,ra s!ch f!nctions, there are
soe thin,s 'e sho!ld o)ser%e.
Programming of parallel sequences
(he f!nctionalit& 'e are aiin, at rese)les that of an operatin, s&ste; se%eral
pro,ras that r!n at the sae tie sho!ld )e sched!led to share the CP$ in order
to let each of the pro,ras )eha%e tiel&. <o'e%er, the conc!rrenc& of coplete
pro,ras is another topic handled later in this )ook. Cor no', 'e ass!e that the
conc!rrenc& stes fro the parallellit& of a sin,le application or pro,ra. 5t is then
a )i, ad%anta,e that separatel& pro,raed conc!rrent acti%ities can share and op-
erate on the sae data str!ct!res or o)6ects. :ther'ise, 'e 'o!ld need additional
files, pipes, sockets, etc. to e*chan,e data, and that 'o!ld )e slo'er and !ch ore
'ork to pro,ra. C!rtherore, ass!e that o!r pro,ra containin, the conc!r -
rentl& e*ec!tin, acti%ities is the onl& pro,ra 'e are r!nnin,. /9e cannot ake as -
s!ptions a)o!t other pro,ras an&'a&, and 'hen 'e load o!r soft'are into an
e)edded cop!ter this ass!ption is norall& f!lfilled.0
9hen an ordinar& se2!ential pro,ra e*ec!tes, fro enterin, the ain pro,ra
!ntil the final end, there is at each tie one specific point of e*ec!tion. 9e refer to
that point in ters of a pro,ra co!nter /PC0. 9e ha%e so far reali@ed that 'e re-
2!ire the pro,ra to )e conc!rrentl& on,oin,, t&picall& e*ec!tin, in se%eral o)6ects
si!ltaneo!sl&. (hat is, the pro,ra has to s'itch )et'een its conc!rrent acti%ities
in s!ch a 'a& that, 'ith the tie scale of the application at hand, it appears /to the
!ser and to the controlled s&ste0 to r!n in parallel /on different CP$s0. (o achie%e
this, the r!n- tie s&ste has to pro%ide1
1& >eal- (ie Pro,rain, H a .a%a- )ased approach
1. A f!nction for creatin, a ne' conc!rrentl& e*ec!tin, acti%it&, i.e., an additional
PC and the states coprisin, the conte*t associated 'ith the point of e*ec!tion.
2. A sched!ler that pro%ides sharin, of the CP$ in coon )& interlea%in, the e*e-
c!tions. (his sho!ld )e 'itho!t re2!irin, the so!rce code to )e cl!ttered 'ith
stateent s not odellin, the task to )e perfored.
+. 9hen conc!rrent acti%ities share the sae data or is dependent on each others
cop!tational res!lts, there !st )e soe eans of s&nchronisation and co! -
(he need for a sched!ler is related to the o)li,ations of the operatin, s&ste for
r!nnin, coplete pro,ras, )!t as entioned, here 'e are concerned 'ith the par -
allel )eha%io!r of one pro,ra. Ass!in, that o!r s&ste is e2!ipped 'ith s!ch a
sched!ler, interlacin, the different points of e*ec!tion, 'e a& define the follo'in,
re2!ireent for a conc!rrent pro,ra to )e correct1
Defini t ion: The correct ness of a concurrent program does not only re3uire each
programmed se3uence of computation to be correct" the correct result must also be ob+
tained for all possible interleavings.
5n ters of the )ank e*aple this eans that one& sho!ld not )e /%irt!all&0 lost or
created d!e to the tiin, of transactions and cop!ter operations. E%en if that is an
o)%io!s re2!ireent, it is act!all& a 2!ite se%ere deand 'hen it coes to %erifica -
tion of the correctness and findin, an& fa!lts; the task 'e call test and de)!,,in,.
De)!,,in, an ordinar& se2!ential pro,ra can )e done )& r!nnin, the pro,ra
'ith all possi)le sets of inp!t data, and one set of inp!t data ,i%es the sae res!lt if
the pro,ra is r!n a,ain. Cor a conc!rrent pro,ra, ho'e%er, the interlea%in, de-
pends on e*ternal e%ents tri,,erin, different se2!ences of sched!lin, and e*ec!tion.
9ith a conc!rrent pro,ra, 'e can !s!all& not e*pect to o)tain the sae e*ec!tion
order t'ice; an inp!t e%ent occ!rrin, 6!st a icrosecond later a& res!lt in another
interlea%in, 'hich a& co!rse an incorrect pro,ra to crash. (hat in t!rn !st not
happen for a safet& critical application. <ence, 'e a& ha%e se%ere re2!ireents on
correctness )!t coplete testin, is alost ne%er possi)le.
5t is interestin, to note that the definition of correctness does not sa& an&thin,
a)o!t tie or tiin,, )!t tiin, is )oth the ain reason for introd!cin, conc!rrenc&
and the ke& aspect for the )eha%io!r of an incorrect pro,ra. Considerin, the diffi-
c!lties 'ritin, and testin, conc!rrent soft'are, o!r hope no' is that 'e can find
and follo' certain r!les for de%elopent of s!ch soft'are.
2.5 Interrupts, pre-emption, and reentrance
.!st like 'e did not allo' the !ser pro,ra to poll the inp!ts for possi)le e%ents
/'hich 'o!ld )e 'aste of cop!tin, po'er 'hen no ne' e%ent has arri%ed0, the
sae applies to the sched!ler or sched!lin,. (he in%ocation of the sched!ler and its
iplications for the soft'are application deser%e soe coents.
200E-01-11 15105 © 1)
Chapter 2 Fundamentals
Obtaining the time base
As entioned, 'e resort to !sin, hard'are interr!pt s to tri,,er o!r soft'are f!nc-
tions, e%en if the interr!pt ser%ice ro!tines as s!ch are hidden inside the operatin,
s&ste and de%ice dri%ers. :f co!rse, 'e a& ha%e inp!t si,nals 'hich do not ,ener -
ate an& interr!pt, )!t then 'e read that %al!e at certain ties, !s!all& periodicall&
'hen the data is !sed for feed)ack control. (herefore, the sched!ler sho!ld also )e
a)le to handle tie re2!ests, s!ch as 3sleep one second4 'hich then sho!ld s!spend
e*ec!tion for that acti%it& d!rin, that period of tie.
<ence, o!r cop!ter !st )e e2!ipped 'ith soe kind of tier interr!pt occ!rrin,
periodicall&, there)& pro%idin, a tie )ase for the soft'are. :f co!rse, the tie in
soft'are 'ill then )e discrete /increented one step for each tier interr!pt0 op-
posed to the tr!e tie 'hich is contin!o!s. Discrete tie is, ho'e%er, inherent to
cop!ter control an&'a& so it s!its o!r p!rposes 'ell.
Note that if 'e 'ere onl& si!latin, o!r s&ste, the tie %aria)le co!ld )e step'ise
increased )& the sched!ler; 'hen all processin, is done for one point of tie, the
sched!ler sipl& lets tie 6!p to the ne*t tie referred to )& the application. 8!t
here 'e ai at soft'are that interacts 'ith the ph&sical en%ironent 'hich /)& the
la's of nat!re0 has tie as an independent and contin!o!sl& increasin, %aria)le.
(he tie %aria)le in o!r soft'are is the sapled %al!e of the real tie.
(he tier interr!pt act!all& t!rns o!t to )e a ,eneral and ini! re2!ireent for
)oth desktop and control cop!ters. Additionall&, there are soe lo'-le%el and s&s-
te- specific e%ents that re2!ire partic!larl& tiel& ser%ice. Cor instance, the 9in-
do's-I5DIG !ser a& re%ie' hisDher 5>S settin,s, t&picall& findin, the allocated
)& the so!nd card, the ,ae port, the hard disk, etc. /(he settin,s are fo!nd )& se-
lectin, 5>S in the panel fo!nd )& clickin, on Control panel -T "&ste -T De%ice
7ana,er -T Cop!ter -T Properties.0 (hen note that the first interr!pt /5>S 00,
ha%in, the hi,hest priorit&0 is !sed )& the 3"&ste (ier4 'hich then pro%ides the
tie )ase for the entire operatin, s&ste. Bi%in, the tier interr!pt the hi,hest
priorit&, allo'in, it to interr!pt other interr!pts, is to ens!re aintenance of the
tie %aria)le. :ther'ise, a too e*cessi%e n!)er of interr!pt s co!ld not )e detected.
5n e)edded cop!ters there are !s!all& also soe kind of tie- o!t or stall- alar
interr!pt connected to the %er& hi,hest /!naska)le0 interr!pt le%el. 5t is then the
o)li,ation of the so called idle loop /the loop )ein, e*ec!ted 'hen there are nothin,
else to do0 to reset that tier so it ne%er e*pires. 8!t if that sho!ld happen, the CP$
is o%erloaded and the controlled achine !st )e sh!t do'n )eca!se 'itho!t
eno!,h tie for the feed)ack control the s&ste a& )eha%e %er& )adl& /cra@& ro)ot,
crashin, airplane, etc.0. (o pre%ent this, 'e 'ill !se special pro,rain, tech-
ni2!es in later chapters. 5n desktop applications, on the other hand, the !ser sipl&
has to 'ait.
1* >eal- (ie Pro,rain, H a .a%a- )ased approach
Interrupts, pre-emption, and reentrance
9hen the sched!ler, as a conse2!ence of a tier interr!pt, s!spends e*ec!tion of
one acti%it& and lets the pro,ra res!e e*ec!tion at another point /'here e*ec!-
tion 'as s!spended at soe earlier sta,e0, 'e call it pre- eption. (he ter is !sed
also in connection 'ith operatin, s&stes; pre- epti%e !ltitaskin,. Pre- eption
eans that e*ec!tion a& )e s!spended e%en if there is nothin, in the e*ec!tin,
code that e*plicitl& adits the chan,e of e*ec!tion point. 9e a& sa& that the s&s-
te forces the applicat ion to ,i%e !p the !se of the CP$.
(he opposite to pre- epti%e sched!lin, is non- pre- epti%e sched!lin,, 'hich eans
that e*ec!tion is onl& s!spended 'hen there is soe call of sched!lin, f!nctions or
reso!rce allocation. Cor instance, an attept to open a net'ork connection a& in-
cl!de 'aitin, for nae- ser%ers and reote cop!ters to repl&. E%en if it is not de-
sira)le to 'ait, 'e kno' /and the copiler and r!n- tie s&ste kno's0 that e*ec!-
tion a& %er& 'ell )e s!spended. (hese so called )lockin, operations are handled
the sae 'hen pre- eption is !sed, )!t 'ith pre- eption the s!spension a& also
)e enforced.
Different t&pes of pre- eption e*ist. 5n ,eneral ters, there are three alternati%es
for the ,ran!lari t& of e*ec!tion s!spension1
1. (he ost priiti%e case is 'hen pre- eption is not s!pported; e*ec!tion is onl&
s!spended 'hen certain s&ste calls are ade. (he ad%anta,e is efficienc& since
the state of the e*ec!tion is 'ell kno'n )& the copiler and r!n- tie s&ste. Cor
instance, all teporar& re,isters that )& the copiler are ass!ed to )e des -
tro&ed )& a f!nction call, need not )e sa%ed. (he disad%anta,e is that an applica -
tion /or f!nction0 'ritten 'itho!t considerin, the need for other acti%ities to e*-
ec!te conc!rrentl& 'ill not ,i%e !p the ri,ht to !se the CP$, and a& therefore
lock the s&ste or ake response ties too lon,.
2. E*ec!tion a& )e interr!ptedDs!spended )et'een each line of so!rce code. Cro
a pro,rain, point of %ie', it is %er& con%enient to kno' that each stateent
,ets f!ll& e*ec!ted 'itho!t interr!pt. Earl&- da&s 8asic interpreters often 'orked
this 'a&. :ne disad%anta,e is that cople* stateents a& dela& chan,e of
acti%it& too lon,. Not to interfere 'ith other interr!pt ser%ices, interr!pt s s!ch as
the tier interr!pt is ser%ed iediatel& and on,oin, e*ec!tion a& )e arked
for s!spension. Another disad%anta,e is then that the checkin, )et'een each
stateent costs processin, po'er. An interestin, %ersion of this techni2!e is i-
pleented in the #!nd "i!la s&ste 'hich )& !tili@ation of the hard'are /"!n
"parc0 perfors the check at alost no cost. (he ke& dra')ack is, ho'e%er, that
conc!rrenc& re2!ires s!pport fro copiler and r!n- tie s&ste, 'hich eans
that ost a%aila)le code /'ritten in CDCJJ0 cannot )e !sed 'hen tiin, re2!ire -
ents are se%ere.
+. E*ec!tion a& )e interr!ptedDs!spended )et'een each achine instr!ction. (he
ad%anta,es are that an& se2!ential code /'itho!t copiler s!pport0 can )e inter -
r!pted, and that the interr!pt and possi)le resched!lin, 'ill )e started iedi -
200E-01-11 15105 © 1,
Chapter 2 Fundamentals
atel&. (here 'ill, ho'e%er, )e soe dela& since 'e !st sa%e the entire stat!s of
the e*ec!tion /all re,isters etc.0, and that a& for soe t&pes of hard'are )e
slo'er than case 2. Another disad%anta,e is that pro,rain, ,ets ore co-
plicated since it a& )e hard to kno' fro the so!rce code if a stateent is ato-
ic or not.
"!in, !p ad%anta,es and disad%anta,es, and considerin, the iportance of
tiel& operation also 'hen non- conc!rrent code is !sed, alternati%e + is the )est
choice. (hat sol!tion is ass!ed in the se2!el. 5n the .a%a case, it is not clear 'hat
'e ean )& achine le%el. (here are three cases1
• (he .a%a pro,ra has )een copiled into )&te code 'hich is then e*ec!ted on a
.a%a Uirt!al 7achine /.U70 hard'are. (hen, the achine instr!ctions act!all&
!sed are the )&te codes, and the pro,ra a& )e interr!pted )et'een each )&te
code 'hich iplies that a stateent in the so!rce code a& )e partiall& e%al! -
• (he .a%a pro,ra, a,ain represented )& its )&te codes, a& )e r!n on a .U7 i-
pleented in soft'are. 5nternall& in the .U7, there a& )e a so called .5( /.!st
5n (ie0 copiler 'hich copiles the )&te codes into nati%e achine code. (he
.U7 a& then perit pre- eption )et'een )&te codes, or )et'een achine in-
str!ctions 'hen perforin, a )&te code, dependin, on ipleent ation. 5n )oth
cases, the .a%a stateents a& )e partiall& e%al!ated.
• 5f 'e kno' 'hat hard'are /and :"0 'e 'ill r!n o!r pro,ra on, there is also the
possi)ilit& to ha%e a con%entional copiler that copiles the .a%a so!rce directl&
into achine code. Also in this case, pre- eption on achine le%el iplies that
e*pressions a& )e partiall& e%al!ated. Cor e*aple, assi,nent of a do!)le
%aria)le a& )e perfored partiall&, res!ltin, in one half of the )&tes fro the
old %al!e and one half fro the ne' %al!e for another thread.
(h!s, fro a pro,rai n, point of %ie', it does not atter 'hich of these cases
that descri)e the act!al sit!ation. (he fact to consider is that o!r se2!ential e*ec!-
tion a& )e interr!pted also in the iddle of one .a%a stateent. 9e 'ill, ho'e%er,
in soe sit!ations kno' that an operation is atoic /one )&te code or one achine
instr!ction dependin, on the case0 and then !tili@e that to siplif& the pro,ra.
No' 'hen 'e ha%e !ltiple points of e*ec!tion in o!r pro,ra, and 'e reali@e that
access of shared data re2!ires special care /'hich 'ill )e co%ered in the ne*t
chapter0, a ,ood 2!estion is1 9hat a)o!t shared f!nctionsM 5n other 'ords1 'hat
happens if the sae f!nction is )ein, called conc!rrentl& fro se%eral points of e*e-
c!tionM 9e sa& that 'e re-enter the f!nction, and if that is peritted and 'orkin,,
'e sa& that the codeDclassDf!nction is reentrant.
#ack of reentrance is coon pro)le in )adl& 'ritten C pro,ras. (he reason is
the !se of static %aria)les, i.e., %aria)les that are allocated on a fi*ed place in
10 >eal- (ie Pro,rain, H a .a%a- )ased approach
Interrupts, pre-emption, and reentrance
eor& instead of on the stack or on the heap.
5n ost r!n- tie s&stes, local %aria)les in f!nctions and )locks are allocated
/p!shed0 on the stack, 'hich eans that the& are deallocated /popped fro the
stack0 'hen the PC lea%es the scope. Data created d&naicall&, !sin, operator ne'
in .a%a or CJJ, are allocated on the heap 'hich is soeties called the free store.
8!t also for heap allocation 'e !s!all& ha%e the reference to the o)6ect declared loc-
all& in soe scope 'hich eans that it is p!t on the stack. (his is a proper pro,ra-
in, st&le 'hich eans that all data is p!shed on the stack of the caller. 5f, on the
other hand, 'e !se static %aria)les, t'o callers of one f!nction 'ill access the sae
local data /referred to )& a)sol!te addresses in the copiled code of the f!nction0.
(he real pro)le is 'hen the one 'ho 'rote the f!nction is not a'are of conc!rrent
pro,rai n,. E*aple1 A n!erical e2!ation sol%er 'as ipleented in C, and
then it 'as packa,ed to,ether 'ith other ro!tines in a li)rar&. (o optii@e the code
for the hard'are at that tie, the teporar& %aria)les of the al,orith 'ere de-
clared static. (he f!nction 'as then s!ccessf!ll& !sed for &ears on an old-st&le $N5V
achine, 'here each pro,ra onl& contains one point of e*ec!tion /e*cept for the
si,nal handlers0. (hen, the li)rar& 'as copiled and linked 'ith applications r!n -
nin, on the ne'er so called !lti- threaded $N5V dialects, s!ch as "!n "olaris, <P-
$V 10 and later, and later %ersions of 5>5V fro "B5. 5t 'as also !sed on the 7i-
crosoft 9in+2 platfor. 5n all these cases, 'hen !sin, the e2!ation sol%er conc!r -
rentl& fro different parts of the application, the res!lts 'ere soeties 'ron,. 5n
this case, the f!nction 'as correct as a pro,ra, )!t not correct 'hen !sed in a con-
c!rrent pro,ra 'here soe interlea%in,s res!lted in !ndesired i*in, of tepor -
ar& data fro different e2!ations.
Also in .a%a it is eas& to declare static %aria)les, )!t 'e sho!ld onl& do that for so
called class %aria)les needed for the str!ct!re of o!r pro,ra, and in that case 'e
sho!ld treat the as other t&pes of shared data /'hich 'e 'ill ret!rn to0. Note that
'hen &o! 'rite an ordinar& f!nction, &o! cannot kno' if it later 'ill )e !sed conc!r -
rentl&. 5n concl!sion, one sho!ld learn conc!rrent pro,rain, )efore doin, an&
t&pe of professional pro,rai n,.
2.6 Models of concurrent execution
(he conc!rrenc& iss!es ade o!r siple se2!ential e*ec!tion odel /fro "ection
2.10 ore cople* )eca!se 'e no' ha%e se%eral se2!ences that interact 'ith each
other. 9ith each se2!ence, there are1
• A PC /the Pro,ra Co!nter0 'hich accordin, to the pre%io!s section refers to the
ne*t achine instr!ction to )e e*ec!ted.
• An "P /the "tack Pointer0 'hich refers to the stack of that partic!lar e*ec!tion
se2!ence. :n the stack, there are the acti%ation records of all )locksDf!nctions
that are c!rrentl& entered, as re2!ired for reentrance.
200E-01-11 15105 © 12
Chapter 2 Fundamentals
• (he achine state /of the CP$ or soe %irt!al achine dependin, on the iple -
entation of the r!n- tie s&ste0 holds part of the stat!s of o!r e*ec!tion se-
• 5f coon reso!rces /like shared data0 are reser%ed in one se2!ence, that affects
the others and sho!ld therefore )e dealt 'ith soeho'.
Contin!in, o!r attept to )rin, order in the cople*it& )& e*plorin, f!ndaent al
properties, soe )asic ters 'ill no' )e descri)ed. Cirst 'e ha%e the follo'in, t'o
Defini t i on: 4 context is the state of an active program e*ecution" which includes
50" S5" and machine state. 2rom an operating system point of view" e*ecution may
also be associated with permission and user privileges which then may be included
in the conte*t. )n such a case we call it a process conte*t or a heavy+ weight conte*t.
2rom this point on" we will use the former mini mal definition which is also called a
light+ weight conte*t.
Defini t i on: 4 context switch refers to the change of conte*t typically performed by
some scheduler or operating system.
"ince 'e ai at appropriate pro,rain, ethods, there is the 2!estion a)o!t
'hat s!pport 'e ha%e fro the lan,!a,e and fro the pro,rain, interfaces /li)-
raries of a%aila)le classes0. (his has a ,reat ipact on the 'a& 'e ha%e to 'rite o!r
code. Cor instance, 'hen pro,rai n, in C, the lan,!a,e itself does not ,i%e an&
s!pport for handlin, conc!rrenc& 'hich akes the !se of special li)raries iportant
/and trick&0. 5n Ada there is lan,!a,e s!pport in ters of tasks and rande6vous , )!t
!sin, that s!pport has a si,nificant ipact on )oth desi,n and ipleent ation. A
lan,!a,e 'ith e*tensi%e s!pport, like :cca, is in dan,er of )ein, too special and
therefore not )ein, 'idel& !sed.
Fundamental abstractions
(he 2!estion no' is, to 'hat e*tend sho!ld a ,eneral p!rpose pro,rain, lan -
,!a,e s!pport conc!rrenc&M As s!,,ested )& 8!hr in a proposed e*tensions of CJJ,
it is appropriate to separate the conte*t fro the e*ec!tion se2!ence as s!ch, and
the follo'in, e*ec!tion properties sho!ld )e s!pported )& the lan,!a,e1
hread - is e*ec!tion of code that occ!rs independentl& and possi)l& conc!rrent
'ith other e*ec!tion. (he e*ec!tion res!ltin, fro one thread is se2!ential
as e*pressed in ordinar& pro,rain, lan,!a,es s!ch as .a%a. 7!ltiple
threads pro%ide conc!rrent e*ec!tion. A pro,rain, lan,!a,e sho!ld
pro%ide feat!res that s!pport creation of ne' threads and specification of
ho' these threads accoplish e*ec!tion. C!rtherore, there !st )e pro-
,rain, lan,!a,e constr!cts 'hose e*ec!tion ca!ses threads to )lock and
s!)se2!entl& )e ade read& for e*ec!tion. A thread is either )locked or r!n -
nin, or read&. A thread is )locked 'hen it is 'aitin, for soe e%ent to oc-
c!r. A thread is r!nnin, 'hen it is act!all& e*ec!tin, on a processor. A
'6 >eal- (ie Pro,rain, H a .a%a- )ased approach
Models of concurrent execution
thread is read& 'hen it is eli,i)le for e*ec!tion )!t is not )ein, e*ec!ted.
Executi on state - is the state inforation needed to perit conc!rrent e*ec!-
tion. An e*ec!tion state can )e acti%e or inacti%e, dependin, on 'hether or
not it is c!rrentl& )ein, !sed )& a thread. An e*ec!tion state consists of the
conte*t and the acti%ation state. (hese are t&picall& stored /internall& in the
r!n- tie s&ste0 in a data str!ct!re, 'hich traditionall& has )een called
process control )lockDrecord /PC>0. An inacti%e e*ec!tion state is then co-
pletel& stored 'ithin the PC>, 'hereas the hard'are related parts /re-
,isters, interr!pt asks, etc.0 of an acti%e e*ec!tion state are stored in the
hard'areDCP$. >eferrin, to the conte*t as the ain ite, 'e call the
chan,e )et'een the acti%e and inacti%e states a conte*t s'itch. (he s'itch
incl!des storin, or restorin, the hard'are state, and it occ!rs 'hen the
thread transfers fro one e*ec!tion state to another.
4utual excl usi on - is the echanis that perits an action to )e perfored on
a reso!rce 'itho!t interr!ption )& other operations on that reso!rce. 5n a
conc!rrent s&ste, !t!al e*cl!sion is re2!ired to ,!arantee consistent
,eneration of res!lts, and it sho!ld therefore )e s!pported in a con%enient
'a& )& the pro,rain, lan,!a,e. C!rtherore, for efficienc& at r!n tie,
it needs to )e pro%ided as an eleentar& e*ec!tion propert&.
5n an o)6ect-oriented frae'ork, these three e*ec!tion properties are properties of
o)6ects. (herefore, an o)6ect a& or a& not ha%eD)e a thread, it a& or a& not
ha%e an e*ec!tion state, and it a& or a& not ha%eDpro%ide !t!al e*cl!sion. (he
latter eans that it a& or a& not e*cl!de conc!rrent access %ia call of ethods of
that o)6ect. (he ne*t iss!e is to kno'1 9hat are the possi)le and !sef!l co)ina -
tions of the e*ec!tion propertiesM All ei,ht co)inations /'hich 'o!ld ake !p a 2
)& 2 )& 2 c!)e0 is depicted in Ci,!re 2-1. (he n!)ers in that ta)le refers to the fol-
lo'in, ites1
1. (his is an ordinar& o)6ect as kno'n fro o)6ect oriented pro,rain,, or an or-
dinar& piece of code in the case that o)6ect orientation is not s!pported. (his is
the onl& case that pro,raers not ac2!ainted 'ith conc!rrent pro,rai n,
!se. A class pro,raed in this 'a& can still )e !sef!l in an conc!rrent en%iron -
200E-01-11 15105 © '1
Figure 2-3 2undamental properties of software e*ecution. Language support for an e*+
ecution property is marked with 7yes8. 2or mutual e*clusion to be support +
ed" it must be implicitly obtained from the types or declarations.
:)6ect pr oper t ies 5plicit !t !al e*cl!sion of et hods
(hr ead E*ec. st at e No Pes
No No :)6ect 7onit or Passi%e o)6ect s
No Pes Cor o!t ine R Co-onit or R Not in . a%a
Pes No Not !sef!l
Pes Pes (hr ead-o)6ect (ask Act i%e o)6ect s
; ;
5 6
7 8
Chapter 2 Fundamentals
ent if its e)er f!nctions are reentrant, 'hich the& are if onl& local data is
!sed and the if lan,!a,eDe*ec!tion s!pports rec!rsion /direct or indirect0. "ince
there is neither a thread nor an e*ec!tion state, 'e sa& that the o)6ect is a pass -
i%e o)6ect.
2. 5t is still a passi%e o)6ect if 'e add !t!al e*cl!sion, )!t onl& one thread at a
tie a& r!n the code of the o)6ect. (his a)straction is called a monitor .
+. <a%in, an e*ec!tion state 'itho!t ha%in, a thread peranentl& associated 'ith
it fors an a)straction called a coro!tine. A coro!tine !st )e !sed )& a thread
to ad%ance its e*ec!tion state. 5f &o! ha%e !ltiple coro!tines )!t onl& one
thread, onl& one coro!tine at a tie a& e*ec!te. (his is !sef!l to handle paral -
lellit& iss!es in al,oriths or in si!lations )eca!se there the /%irt!al0 tie of
the odel can )e held or ad%anced ar)itraril&. (hat is, the real tie !sed )& a
specific thread for its e*ec!tion is !niportant, and a sin,le thread !sin, !l -
tiple coro!tines is appropriate. An ipleentation )ased on coro!tines can al -
'a&s )e re'ritten to 'ork 'itho!t the, )!t that a& re2!ire ore cople* data
str!ct!res and code. 5n co)ination 'ith tier interr!pts tri,,erin, a sched!ler,
coro!tines can )e !sed to ipleent thread o)6ects.
4. Addin, !t!al e*cl!sion to coro!tines is not reall& necessar& in the case of 6!st
one thread, and in the case that a ,ro!p of coro!tines r!n )& one thread interacts
'ith other threads, this alternati%e leads to diffic!lt and error- prone pro,ra -
in,. (he nae co-onitor is not esta)lished and this case is neither !sed nor
coented in the se2!el.
5. A thread 'itho!t an e*ec!tion state cannot e*ec!te on its o'n, and )orro'in, an -
other thread for its e*ec!tion does not pro%ide conc!rrenc&. (his case it therefore
not !sef!l.
E. Also 'ith !t!al e*cl!sion, this case is not !sef!l for the reasons entioned in
ite 5.
F. An o)6ect 'ith )oth thread and e*ec!tion state is capa)le of e*ec!tion of its o'n.
9e call this an acti%e o)6ect or a thread o)6ect. (he pro)le is that access to the
attri)!tes re2!ires e*plicit !t!al e*cl!sion. (hat has to )e siple to e*press in
the pro,ra in order to ake this alternati%e !sef!l. Note that e%en if an acti%e
o)6ect calls e)er f!nctions of other /acti%e or passi%e0 o)6ects, the e*ec!tion of
those f!nctions is dri%en )& the callin, thread, and the stacked acti%ation records
are part of the callers e*ec!tion state.
G. A thread o)6ect 'ith iplicit !t!al e*cl!sion is called a task. (his a)straction
can )e fo!nd in the Ada lan,!a,e.
(he a)stractions s!pported )& different pro,rain, lan,!a,es differs. Conc!r -
renc& in the Ada lan,!a,e is )ased on the task, 'hich in that lan,!a,e is a!,en -
ted 'ith a specification of ho' s!ch o)6ects interact. 7od!la- 2 pro%ides coro!tines
'ith pre- eption 'hich allo's a pre- epti%e sched!ler /s!pportin, threads0 to )e
)!ilt. "i!la pro%ides coro!tines that, to,ether 'ith interr!pts checked )et'een
'' >eal- (ie Pro,rain, H a .a%a- )ased approach
Models of concurrent execution
each stateent, can )e !sed to )!ild a sched!ler and thread s!pport. Neither "i-
!la nor 7od!la s!pport iplicit !t!al e*cl!sion, 'hich eans that shared data
!st )e e*plicitl& reser%ed )& callin, certain f!nctions for lockin, and !nlockin,. 5n
C and CJJ, there is no conc!rrenc& s!pport at all.
Concurrency in Java
"o, 'hat are then the desi,n choices for .a%aM As 'ith other parts of .a%a, 'e find
fair en,ineerin, choices rather than ne' !ni2!e feat!res.
• (here is no iplicit !t!al e*cl!sion on o)6ect le%el, )!t indi%id!al ethods /and
e%en )locks0 iplicitl& pro%ide !t!al e*cl!sion )& the e*plicit !se of the s&n-
chroni@ed ke&'ord. $nfort!nat el&, onl& code and not the accessed data is s&n-
chroni@ed. "oe e*tra pro,rai n, discipline is therefore still re2!ired. Co-
pared to ha%in, iplicit !t!al e*cl!sion f!ll& )!ilt into the lan,!a,e, the ad-
%anta,e is that the pro,raer is ore free to tailor hisDher code for specific ap-
plication needs /s!ch as efficienc&0.
• (he notion of a thread o)6ect is s!pported %ia the o)6ect orientation )& inherit -
ance fro the (hread )ase- class. 9hen inheritance is rather !sed for other prop-
erties /recall that .a%a onl& pro%ides sin,le inheritance0, the interface Runnable
can )e !sed to add the thread propert& to an o)6ect.
• Coro!tines are not s!pported. Norall&, threads are !sed to achie%e the parallel
)eha%io!r of coro!tines. (herefore, lar,e- scale e%ent- dri%en si!lations a& )e
%er& inefficientDslo'.
5n noral applications, incl!din, e)edded s&stes,
thread o)6ects pro%ide alost the sae e*ec!tion efficienc&. (he a6or reasons
for oittin, the coro!tines in the .a%a lan,!a,e are1 10 (he lan,!a,e can )e kept
sipler. 20 7ost pro,raers do not kno' ho' to !tili@e coro!tines an&'a&, par -
tic!larl& not in co)ination 'ith threads. +0 <a%in, the pro,raer to !se
threads instead eans that the r!n- tie s&ste is free to let acti%ities r!n in
parallel if there are !ltiple CP$s a%aila)le.
• (he threads are )ased on so called nati%e ethods, i.e., f!nctions that are iple -
ented e*ternal to the .U7. 5n the case of thread s!pport, nati%e ethods a&
)e ipleented )& the operatin, s&ste. (hread creation, interaction, and
sched!lin, are then handled )& the s&ste f!nctions 'hich are optii@ed for the
act!al hard'are !sed /and r!n in parallel as entioned in the pre%io!s ite0. :f
co!rse there is a lack of ele,ance copared to a s&ste )ased on coro!tines, ha%-
in, the sched!ler ipleented as in the lan,!a,e itself. <o'e%er, for the a6or -
it& of applications r!nnin, on an operatin, s&ste s!ch as the "olaris operatin,
s&ste /the "!n $N5V 'hich s!pports !p to E4 processors0, !sin, the nati%e
threads )oosts perforance /'itho!t chan,in, the so!rce code0.
2 (o o%ercoe this /!n!s!al0 pro)le, a s!perset of the .a%a lan,!a,e and a dedicated
copiler and r!n- tie s&ste /replacin, the .U70 co!ld )e de%eloped. 8& ipleentin,
the lan,!a,e e*tensions as a translator ipleented in .a%a, ,eneratin, ordinar& .a%a-
code, the application 'o!ld still )e 100W .a%a 'hen not optii@ed.
200E-01-11 15105 © '3
Chapter 2 Fundamentals
5n concl!sion, .a%a pro%ides passi%e o)6ects and acti%e o)6ects. A passi%e o)6ect is
either an ordinar& o)6ect, or it can )e an o)6ect 'ith no data e*posed and all eth -
ods s&nchroni@ed 'hich then f!nctions like a onitor. (here are, ho'e%er, no real
onitors in the lan,!a,e; the pro,raer a& e*pose data to conc!rrent access
and soe ethods a& )e left !ns&nchroni@ed. Acti%e o)6ects are those 'ith the
thread propert&, )!t 'e do not ha%e /and 'e 'ill not talk a)o!t0 tasks since 'e do
not ha%e threads 'ith iplicit !t!al e*cl!sion. 9e 'ill therefore onl& speak a)o!t
classes, o)6ects, s&nchroni@ed ethods, and threads. (hese are o!r )!ildin, )locks
for conc!rrent and real- tie pro,rain,. (here is, ho'e%er, %er& little s!pport for
handlin, tiin, re2!ireent s, 'hich 'e 'ill ret!rn to in the final chapters.
Processes and interrupts
5n the a)o%e treat ent of pro,rai n, lan,!a,e s!pport for conc!rrenc&, 'e ne,-
lected t'o aspects, processes and interr!pt ser%ice ro!tines. 5n short, a process is
the t&pe of conc!rrent e*ec!tion 'e ha%e 'hen 'e r!n soe pro,ra !nder an oper -
atin, s&ste s!ch as $N5V or 9indo's N(, and an interr!pt ser%ice is the conc!r -
rent e*ec!tion 'e ha%e 'hen a hard'are interr!pt starts a ne' thread of e*ec!tion.
(hese ha%e to do 'ith the interaction )et'een the .a%a pro,ra and its en%iron -
ent in ters of hard'are or other pro,ras. "ince this is 2!ite dependent of the
specific en%ironent, it is pro)a)l& a ,ood idea not to pro%ide an& lan,!a,e s!pport.
5nstead, 'e !se classes that pro%ide certain pro,rain, interfaces. <ere, 'e 'ill
!se the ter interr!pt to denote the e*ec!tion carried o!t to ser%ice the act!al hard -
'are interr!pt.
8oth a process and an interr!pt contain threadin, and soe kind of e*ec!tion state,
)!t a process is ore po'erf!l than a thread 'hereas an interr!pt is less po'erf!l.
5n ore detail1
• A process a& contain one or se%eral threads 'hich 'e then sa& are internal to
the process. (he internal threads share a coon address space in 'hich the&
can share data and co!nicate 'itho!t ha%in, to cop& or transfer data %ia
pipes or files. An o)6ect reference /or pointer in CDCJJ0 can )e !sed )& se%eral
threads, )!t sharin, o)6ects )et'een processes re2!ires special techni2!es. (he
sae applies to calls of e)er f!nctions. All threads of one process ha%e the
sae access ri,hts concernin, s&ste calls, file access, etc. Different processes,
on the other hand, a& ha%e different access ri,hts .
(he concept of a process akes it possi)le to isolate e*ec!tion and data refer -
ences of one pro,ra. 8& controllin, the 77$ /7eor& 7ana,eent $nit0 ac-
cordin,l&, an ille,al data access /d!e to dereference of a dan,lin, pointer in a C
pro,ra for instance0 can )e trapped and handled )& the operatin, s&ste. (o
the $N5V !ser, there 'ill )e soethin, like a 3se,ent ation fa!lt4 essa,e. 5n
9indo's I5DIG, 'hich lacks this s!pport, one application pro,rain, error a&
crash other applications or e%en han, the operatin, s&ste.
'& >eal- (ie Pro,rain, H a .a%a- )ased approach
Models of concurrent execution
• An interr!pt starts a ne' e*ec!tion thread, )!t it is s!)6ect to special restric -
tions. Cirst, it !st coplete 'itho!t )lockin, )eca!se it a& not chan,e e*ec!-
tion state /s'itch conte*t 0. "econd, the interr!pt a& onl& start in a static f!nc-
tionDethod )eca!se this t&pe of hard'are call does not pro%ide f!nction ar,! -
ents s!ch as the iplicit this pointer. (hird, an interr!pt a& r!n 'ithin the
conte*t of another thread )eca!se the final restore of !sed re,isters and the re-
2!ireent of 3e*ec!tion !ntil copletion4 ens!res that the conte*t of the inter -
r!pted thread 'ill )e restored. (he priorities of interr!pts are ana,ed )& the
(h!s, 'hereas threads 'ill )e the ost coon 'a& to accoplish conc!rrentl& e*-
ec!tin, soft'are entities, an 5"> is soeties ore appropriate or e%en necessar&
/de%ice dri%ers0, or there a& )e reasons for !sin, /:"0 processes instead of threads.
De%ice dri%ers cannot )e /p!rel&0 ipleented in .a%a, and s!ch achine- le%el pro-
,rain, is o!tside the scope of this )ook; it is 'ell kno'n ho' to do that and there
are se%eral hard'areD:"- specific an!alsD)ooks on the topic. (he iss!e of !lti -
threadin, %ers!s !ltiprocessin, is ore rele%ant, in partic!lar for lar,e cople*
s&stes, deser%in, a ore detailed treat ent.
2.7 Multi-process programming
Pro,rai n, lan,!a,es incl!de constr!cts for e*pressin, the e*ec!tion of one pro-
,ra, 'hile interaction )et'een pro,ras are handled %ia li)rar& calls. E*ercises in
)asic pro,rai n, co!rses are sol%ed )& 'ritin, one pro,ra, possi)l& in se%eral
files that are copiled separatel&, )!t linked as one e*ec!ta)le !nit 'hich is e*ec!t -
ed 'ithin one :" process. Possi)l&, e%ent handlers /in ters of e%ent listeners or
call)ack ro!tines0 or !ltiple threads are !sed, )!t it is one pro,ra and one pro-
cess sharin, a coon eor& space. Note that e%en if 'e let different :" process -
es share eor& /%ia s&ste calls s!ch as mmap in $N5V0, 'e ha%e no lan,!a,e s!p -
port for si,nalin, and !t!al e*cl!sion; that too has to )e handled %ia s&ste calls.
$sin, !ltiple threads /!lti- threaded pro,rain,0 can, in principle, as en -
tioned, )e !sed to create an& conc!rrenc&. Also for !tili@ation of !ltiple CP$s /'ith
shared eor&0, threads are eno!,h. "o, in real- 'orld s&stes, 'hat are the rea -
sons for !sin, !ltiple processes instead of 6!st !ltiple threadsM 5n short, reasons
for di%idin, a soft'are application into !ltiple :" processes incl!de the follo'in,1
1. Different parts of the applications need to r!n on different cop!ters 'hich are
distri)!ted /not sharin, eor&0.
2. Different parts of the application need different perissions and access ri,hts, or
different sets of s&ste reso!rces.
+. 5n the .a%a case, different %irt!al achine properties /s!ch as BC properties0 can
)e desira)le for different parts of the s&ste, dependin, on tiin, deands etc.
200E-01-11 15105 © ')
Chapter 2 Fundamentals
4. 5f the application consists of /ne'0 .a%a parts and other /t&picall& old, so called
le,ac&0 parts 'ritten in other lan,!a,es like C, these parts can )e interfaces and
linked to,ether !sin, the .a%a Nati%e 5nterface /.N50. <o'e%er, if the %irt!al a -
chine and the le,ac& code re2!ires specific )!t different nati%e threadin, li)rar -
ies, this a& not )e possi)le /res!ltin, in linka,e errors0. (his is sol%ed )& !sin,
!ltiple processes.
5. #icensin, ters for different parts of the application can for)id e*ec!tion as one
process. Cor instance, BN$- t&pe of free soft'are /BP#0 a& not )e linked 'ith
proprietar& soft'are.
E. A lar,e application incl!din, code 'ritten in an !nsafe lan,!a,e /s!ch as CDCJJ0
'ill )e ore relia)le if it is di%ided into se%eral e*ec!ta)le !nits, each 'ith its
o'n eor& space and 'ith eor& accesses checked )& the 77$ /eor&
ana,eent !nit0 hard'are. 5nstead of a =)l!e- screen= d!e to an ille,al access,
6!st one part of the application a& stop. (he !se of protected eor& is a ain
reason 'h& lar,e s&stes ha%e )een possi)le to de%elop despite !nsafe lan,!a,es.
"till, an& pro,ra a& contain fatal )!,s, )!t a safe lan,!a,e s!ch as .a%a en-
s!res that at least the errors are kept local and e*ception handlin, 'orks.
F. #i)raries, s!)s&stes, or le,ac& soft'are in ,eneral a& not )e thread safe. (hat
is, %aria)les /or attri)!tes or fields0 for stora,e of local data 'ithin a f!nction /or
ethod or proced!re0 a& )e declared static. (hat !sed to )e a 'a& to speed !p
pro,ras and to sa%e stack space, )!t the res!lt is that the f!nction can onl& )e
called )& one thread at a tie. 8& o)tainin, conc!rrenc& onl& %ia :" processes,
'e do not ha%e to re2!ire the soft'are to )e thread safe since each process has its
o'n eor& allocated )& the :".
"oeties &o! a& 'ant to de%elop classes and acti%e o)6ects 'hich can )e r!n
either as threads or as a processes, 'itho!t chan,in, the code. "!ch iss!es and the
principles of ho' to desi,n and ipleent !lti- process applications are topics of
Chapter F.
Note that fro a concurrent design point of %ie', ne,lectin, ipleentation iss!es
s!ch as if conc!rrenc& sho!ld )e accoplished )& threads or processes, 'e !s!all&
!se the ter process to refer to a /conc!rrentl& e*ec!tin,0 acti%it&. (his is in line
'ith non- technical %oca)!lar& 'here a process refers to soe on,oin, acti%it& that
cannot )e copleted iediatel&. /Pa& attention to ho' the 'ord is !sed in the
ne's, in econo&, and in ana,eent principles.0
2.8 Object interaction and encapsulation
(he interaction /inforation e*chan,e0 )et'een o)6ects a& )e s&nchrono!s or
as&nchrono!s. 5t can )e )!ilt into the pro,rain, lan,!a,e, andDor it can )e pro-
,raed. "&nchrono!s co!nication can )e ipleented on top of as&nchrono!s
co!nication, or %ice %ersa.
'* >eal- (ie Pro,rain, H a .a%a- )ased approach
Object interaction and encapsulation
<ere, 'e consider s&nchrono!s co!nication as ore f!ndaent al. 9ith the e*e-
c!tion properties of .a%a this sipl& eans a ethod in%ocation, 'hich is )ased on
ordinar& f!nction calls /'orks e*actl& as in CDCJJ and ost other lan,!a,es0. (h!s,
it is )!ilt into the lan,!a,e. (his is the ost cop!tin,- efficient 'a& to achie%e o)-
6ect interaction in copiled lan,!a,es.
(he as&nchrono!s co!nication eans passin, soe kind of essa,e 'itho!t re-
2!irin, the senderDcaller to 'ait !ntil the recei%erDcallee replies; the caller perfors
its co!nication as&nchrono!sl& 'ith the callee. (he essa,es are often referred
to as e%ents. 8!t note, ho'e%er, ost of the e%ent processin, done for instance in
.a%aRs A9( or 7icrosoftRs 7CC act!all& constit!tes s&nchrono!s co!nication )e-
ca!se there are no )!ffers pro%idin, the as&nchrono!s )eha%io!r. 5t depends on the
application deands if 'e 'ant )!fferin, or not. 9e 'ill take a closer look at this
iss!e in later chapters.
5n this chapter 'e ha%e re%ie'ed the properties of soft'are e*ec!tion, as e*pressed
in the so!rce code. (he iss!es 'e are a)o!t to st!d& are a)o!t soft'are de%elop-
ent, ass!in, that the !nderl&in, /%irt!al0 achine achine /and s&ste soft -
'are0 is correct. Ass!in, also that the copiler is correct /prod!cin, )inar& code,
prefera)l& efficient, that )eha%es as e*pressed in the so!rce code0, 'e i,ht )elie%e
that 'e co!ld do the pro,rai n, in an& /con%enient0 lan,!a,e. <o'e%er, if a pro-
,ra /for instance d!rin, testin,0 'orks correctl&, and is correct fro the conc!r -
renc& point of %ie', 'e cannot kno' that the pro,ra 'orks correctl& in another
case, e%en if it 'as tested 'ith all co)inations of inp!t data. (he reason is that
ost lan,!a,es do not pre%ent pro,ras 'ith !ndefined )eha%io!r, 'hich a& res -
!lt in daa,ed data 'ithin the sae o)6ect or at an& other location 'ithin the pro-
,ra, or e%en o!tside the pro,ra if the :" does not pro%ide eor& protection.
$ndefined )eha%io!r can ste fro !se of !ninitiali@ed data, dan,lin, pointers, !n -
checked t&pecasts, etc. (herefore, in order to )e a)le to )!ild s&stes that scale !p
for cople* applications, 'e sho!ld !se a lan,!a,e that onl& perits 'ell-defined
pro,ras. 9e call s!ch a lan,!a,e safe.
Defini t ion: 4 programmi ng language is safe if and only if all possible e*ecutions of
any program written in that language is e*pressed by the program itself.
5n partic!lar, .a%a is safe /)!t nativeD!nsafe code can )e called0, CK is not 2!ite
safe /safe e*cept 'here the ke&'ord unsafe is !sed, or 'hen nati%e code is called0,
Ada is !nsafe, 'hile C and CJJ are clearl& !nsafe. E%er& lan,!a,e !st perit !n -
safe code to )e called, other'ise de%ice dri%ers co!ld not )e !sed. Po! a& consider
it as a deficienc& that neither %ir!ses nor de%ice dri%ers can )e 'ritten in .a%a;
soe ipleent ation has to )e done in soe other lan,!a,e. :ne co!ld also consid-
er it as an ad%ant a,e; hard'are access /'hich 'ill not )e porta)le an&'a&0 has to )e
'ritten 'ell separated fro the rest of the application. (hose /!s!all& sall0 pieces
of soft'are also ha%e to )e ore thoro!,hl& de)!,,ed since a pro,rai n, error
co!ld crash the entire s&ste 'itho!t e*ception handlin, of s&ste sh!tdo'n 'ork -
in,, opposed to safe pro,ras 'hich terinates in a controlled 'a& 'ith s!per%isor&
f!nctions and reco%er& s&stes still r!nnin,. 9e !se a .a%a- )ased approach to e-
200E-01-11 15105 © ',
Chapter 2 Fundamentals
)edded s&stes pro,rain, since 'e need to tr!st their )eha%ior.
2.9 Software issues
8ased on the properties of soft'are e*ec!tion in ,eneral, and on the, for o!r p!r -
poses, 2!ite ,ood desi,n choices ade in the .a%a lan,!a,e, 'e are no' read& to
tackle the iss!e of conc!rrent and real- tie pro,rain,. (o s! !p, 'e sho!ld )e
a)le to de%elop soft'are s!ch that the follo'in, is o)tained1
• Correctness fro a conc!rrent point of %ie'; all allo'ed interlea%in,s as e*-
pressed in the so!rce code sho!ld res!lt in the sae correct res!lt independent of
the !nderl&in, sched!ler or operatin, s&ste.
• Correctness fro a real- tie point of %ie'; the tiin, re2!ireent s are con-
sidered so that control o!tp!t is cop!ted in tie.
• Proper o)6ect oriented desi,n and ipleent ation; 'e !se the esta)lished prin -
ciples of o)6ect orientation to ipro%e str!ct!re, reada)ilit&, aint aina)ilit&, etc.
of e)edded soft'are.
• Appropriate trade- off )et'een acti%e and passi%e o)6ects; the thread class sho!ld
)e !sed 'here appropriate )!t not too e*cessi%e for efficienc& and reada)ilit&
• Proper protection of shared reso!rces; the concepts of seaphores, s&nchroni@ed
ethods, and essa,es /e%ents0 sho!ld )e !sed appropriatel&.
"ince soft'are de%elopent tends to take a )i,,er and )i,,er part of s&ste de%el -
opent reso!rces, it is %er& iportant that 'e are a)le to handle the a)o%e ites. 5n
a 'ider perspecti%e, there are different approaches to de%elopent of e)edded s&s-
tes. (he foc!s co!ld )e on hard'are, control theor&, andDor soft'are iss!es. All of
these foc!ses are iportant for ind!strial de%elopent of control s&stes. <ere 'e
approach the de%elopent of e)edded soft'are fro a pro,rai n, point of %ie',
lea%in, the rest /like selection of cop!tin, and 5: hard'are, discreti@in, control
al,oriths, etc.0 for other )ooks.
'0 >eal- (ie Pro,rain, H a .a%a- )ased approach
4ulti$ hreaded Pro1rammi n1
Chapter +7!lti- (hreaded Pro,rain,
!oal: To be able to write concurrent programs using standard Java.
ith !nderstandin, of application deands and concepts presented in pre%io!s
chapters, 'e 'ill in this chapter look into the iss!e of handlin, conc!rrenc&
'ithin one pro,ra, !tili@in, the feat!res of the .a%a- platfor. Ac2!aint ance 'ith
)oth /se2!ential pro,rain, in0 .a%a and o)6ect oriented pro,rain, /::P0 is
ass!ed. (he follo'in, properties and restrictions sho!ld )e clear to the reader1
• :ne pro,ra eans one e*ec!ta)le !nit in 'hich different o)6ects /possi)l& con-
c!rrentl&0 can address data in a coon eor& space. (he pro,ra is r!n ei-
ther as one process !sin, an :peratin, "&ste /:"0 or as an e)edded applica -
tion linked to,ether 'ith a so called real- tie kernel /or >(:"0.
• As sho!ld )e clear fro the application e*aples, the soft'are needs to respond
to conc!rrentl& occ!rrin, e*ternal e%ents. "e2!ential cop!tin, and handlin, of
se2!ences of s!ch e%ents, e*pressed as ordinar& se2!ential pro,ras, then has to
)e e*ec!ted conc!rrentl&.
• 8& sipl& !sin, the concept of thread o)6ects, 'e ass!e that the !nderl&in,
:"Dkernel /'hich incl!des a sched!ler0 sched!les the conc!rrent threads /nor -
all& an&0 for e*ec!tion on the a%aila)le CP$s /norall& one0. <ence, the s&s-
te interlea%es the code at r!n- tie )ased on s&ste calls 'hich ha%e )een pro-
,raed accordin, to this chapter.
• Cor the soft'are to )e correct, it sho!ld prod!ce the correct res!lt re,ardless of
the act!al interlea%in,. (hat is, the correct res!lt sho!ld )e o)tained for an& in-
terlea%in, /for ,i%en inp!t se2!ences0 that copl& 'ith the pro,raed s&ste
calls. (he correct res!lt a& depend on tie, and different actions co!ld )e taken
dependin, on tie, )!t there is no ,!arantee concernin, the tie of e*ec!tion.
• "pecificall&, priorities are s!,,estions for the sched!lin, /and there)& the tiin,0
)!t the correctness a& not depend on priorities. C!rtherore, 'aitin, a spe-
cified tie /sleep0 or !ntil a specified tie /sleepUntil0 onl& eans that e*ec!-
tion is s!spended for at least that lon,. (hat perits the sched!ler to ha%e other
threads r!nnin, d!rin, the specified ao!nt of tie, )!t the soft'are alone does
not specif& an& !pper liit of the real- tie dela&.
(hese are )asicall& the preconditions for the .a%a platfor. 5t a,rees 'ell 'ith con-
c!rrenc& for 5nternet applications; the net'ork e*hi)its !npredicta)le tiin, an&-
'a&. 5t also a,rees 'ith the properties of the ost 'ell-kno'n operatin, s&stes
s!ch as $ni* /"olaris, #in!*, etc.0 and 9indo's- N(. 9ith no f!rther ass!ptions,
o!r conc!rrent s&ste is not a real- tie s&ste. /8& si!latin, the en%ironent 'e
can, ho'e%er, si!late a real- tie s&ste and carr& o!t alost all of the soft'are
test and de)!,,in,.0
<ence, !lti- threaded pro,rai n, /i.e., conc!rrent pro,rai n, )ased on
threads0 sho!ld therefore not )e conf!sed 'ith real- tie pro,rain, 'hich 'e
200E- 01-11 15105 L '2
Chapter 3 Multi-Threaded Programming
'ill cope 'ith in later chapters, 6!st a fe' f!rther coents here1
5n order to o)tain correctness fro a real- tie point of %ie', a conc!rrent pro,ra
has to )e r!n on a real- tie platfor. "!ch a platfor !st f!lfil additional re2!ire -
ents concernin, CP$- speed, a%aila)le eor&, 5: and interr!pt handlin,,
sched!lin, al,oriths, and the inp!t to the sched!ler fro the application soft'are.
E%en on a non- real- tie platfor 'e a& o)tain a s&ste )eha%io!r that appears to
)e real- tie. A coon approach, for instance 'hen !sin, PCs in ind!strial a!to -
ation, is to onl& let one or a fe' 'ell-kno'n pro,rasDdaeonsD ser%ices r!n, to
ha%e soe acti%ities r!n in soe kind of kernel or dri%er ode, to tailor the applica -
tion soft'are for ipro%ed handlin, of sporadic dela&s /for instance )& teporaril&
ad6!stin, paraeters and decrease perforance0, and )& !sin, a po'erf!l cop!ter.
"till, since the s&ste is not ,!aranteed to prod!ce a 2!ite correct res!lt at the ri,ht
tie, it is not real tie. 8!t fro an application point of %ie', the s&ste )eha%io!r
can )e ,ood eno!,h. (herefore, in a practical ind!strial conte*t the )orderline
)et'een real- tie and conc!rrent pro,rain, is not that clear.
3.1 Threads
Cor no' 'e ass!e that o!r conc!rrent acti%ities can r!n independentl& of each
other, 'ith no need for s&nchroni@ation and !t!al e*cl!si%e ethods.
Thread creation
At start of a .a%a Uirt!al 7achine /.U70, the so called ain thread starts e*ec!tin,
the .a%a pro,ra )& callin, the ain ethod of the class ,i%en to the .U7. 5n case
of an applet, the sae applies )!t then the ain ethod is part of the host applica -
tion, 'hich in t!rn calls the appletRs init ethod. (o ha%e another thread r!nnin,, a
s&ste call has to )e done /'ithin the .U7 or to the :", at this sta,e 'e donRt care
5n ost pro,rain, lan,!a,es there is no )!ilt- in s!pport for conc!rrenc&, and
creatin, ne' threads has to )e done %ia a platfor and lan,!a,e specific s&steD
li)rar& call. 5n the .a%a platfor, 'e ha%e to create an o)6ect of t&pe java.lang.-
Thread and call its ethod start /'hich is nati%e, i.e., not 'ritten in .a%a0. (he
caller of start ret!rns as for an& ethod call, )!t there is also a ne' thread copet -
in, for CP$ tie. (he ne'l& created thread !st ha%e an entr& point 'here it can
start its e*ec!tion. Cor this p!rpose there !st )e a r!nna)le o)6ect a%aila)le to the
thread o)6ect. A r!nna)le o)6ect pro%ides a ethod r!n accordin, to the interface
java.lang.Runnable; that interface sipl& declares a public void run() and noth -
in, ore. 5t is that r!n ethod &o! sho!ld ipleent to accoplish the conc!rrent
9hat r!n ethod to )e called )& start is deterined at thread- o)6ect creation tie,
i.e., 'hen the thread o)6ect constr!ctor is r!n. (here are t'o alternati%es dependin,
on 'hat constr!ctor that is !sed, e*tendin, a thread o)6ect or ipleentin, a r!n -
36 >eal- (ie Pro,rain, H a .a%a- )ased approach
na)le o)6ect1
• 8& extendi n1 class Thread, Runnable 'ill )e ipleented since public class
Thread extends Object implements Runnable. 5n other 'ords, this 'ill )e an
instance of Runnable. (he defa!lt constr!ctor 'ill select as the )e,in-
nin, for the ne' thread .
Ad%anta,es 'ith this alternati%e is that &o! can o%erride also the start ethod
/to do soe thin,s )eforeDafter thread creationDterination, callin, super.start
in )et'een0, !tilit& ethods of class Thread can )e called 'itho!t 2!alification
and askin, the r!n- tie s&ste for the c!rrentl& e*ec!tin, thread /descri)ed in
the se2!el0, and the inheritance is a ,ood )asis for de%elopin, f!rther threadin,
s!)classes /as done in later chapters0.
• 8& implementi n1 the Runnable interface, the o)6ect can )e passed to the
Thread constr!ctor 'hich then 'ill !se the r!n of the s!pplied o)6ect as the )e-
,innin, for the ne' thread. (he ad%anta,e 'ith this approach is that the /in .a%a
sin,le0 inheritance can )e !sed for other p!rposes, s!ch as inheritin, ,raphical
5n short, as indicated in the second ite, 'hich alternat i%e that is ost s!ita)le de-
pends on the priar& iss!e of the soft'are. Cor instance, a ,raphical !ser interface
!sin, the javax.swing classes and onl& soe threadin, for handlin, the net'ork
'ill pro)a)l& inherit ,raphical properties and ipleent Runnable 'hen needed.
Cor an e)edded control application, on the other hand, threadin, /and tiin,0 is a
priar& iss!e and inheritance fro class Thread is a nat!ral choice.
"oe pro,raers prefer to al'a&s !se the Runnable alternati%e as their standard
'a& of doin, thin,s, 'hereas others al'a&s create Thread s!)classes /soeties
ha%in, an internal thread o)6ect 'hen there is a need to inherit fro other classes0.
5n the se2!el, threadin, is the priar& iss!e so 'e 'ill ostl& !se Thread as a )ase
class, )!t !tili@in, interface Runnable is co%ered as 'ell.
E%en tho!,h conc!rrent pro,ras do not ens!re tiin,, it is %er& !sef!l to let ac-
tions depend on real tie, i.e., readin, the real- tie clock 'hich is a%aila)le on an&
!sef!l cop!tin, platfor. 5n .a%a the defa!lt tie !nit is illiseconds, and the
c!rrent clock tie is o)tained )& callin, System.currentTimeMillis 'hich ret!rns
the tie in illiseconds co!nted fro )e,innin, of 1IF0. "ince the ret!rn %al!e is of
t&pe lon,, the &2k t&pe of pro)le that coes 'ith the finite tie ran,e is 2!ite far
in the f!t!re /&ear 2I22F2II+, 'hich sho!ld ean no pro)le for ost
(he ad%ant a,e 'ith currentTimeMillis stored in a )!ilt in n!eric datat&pe /lon,0
is that it can )e con%enientl& !sed for cop!tations. Cor h!an- reada)le tie .a%a
also pro%ides a Date class 'hich also copes 'ith tie @ones, locales, and the like.
(hat is, ho'e%er, a atter of forat tin, and for o!r needs it is the s&ste tie in
200E-01-11 15105 © 31
Chapter 3 Multi-Threaded Programming
illiseconds that is rele%ant.
Ass!e 'e 'ant to cop!te the trend /or n!erical deri%ati%e0 of an analo, inp!t
si,nal. C!rther ass!e 'e ha%e a ethod inValue that handles the AD con%ersion
and ret!rns a scaled %al!e as a float, and let !s sa& that 'e ha%e an infinite resol! -
tion in %al!e. Concernin, resol!tion in tie, 'e ha%e the illisecond tie descri)ed
a)o%e. (hat tie is !pdated %ia a clock interr!pt ro!tine in the .U7 or :". "oe
e)edded cop!ters are e2!ipped 'ith a hi,h resol!tion real- tie clock, )!t !sin,
it 'o!ld re2!ire a nati%e ethod and loss of porta)ilit&. $sin, onl& the standard 1
s resol!tion, an attept to cop!te the trend co!ld )e1
1: float trend() {
2: float x, x0 = inValue(); // [V]
3: long t, t0 = System.currentTimeMillis();
4: while ((t=System.currentTimeMillis())==t0){/*Busy waiting.*/};
5: x = inValue();
6: return (x-x0)/(t-t0)*1000; // [V/s]
7: }
9ith an inp!t si,nal that increases constantl& 'ith 1 UDs 'e 'o!ld like to o)tain the
%al!e 1.0, )!t alread& 'ith s!ch a sall piece of soft'are it is hard to foresee the
%al!e act!all& ret!rned. #et !s look into a fe' )asic aspects1
• (ie 2!anti@ation1 9aitin, for the ne*t s does not ean 'aitin, for 1 s. 5n
fact, r!nnin, on a 100 7<@ CP$ it a& take onl& 10 nano- seconds /1 CP$ c&cle0
!ntil a ne' clock interr!pt is ser%ed and the tie /in soft'are0 is increented.
(he real tie )et'een the readin,s 'ill then )e onl& the tie to r!n lines 2 to 5,
pl!s the ser%ice tie for the clock interr!pt, sa& 0.1 !s ,i%in, a relati%e error of
1000000WX 5,norin, the /2!ite sall0 cop!tation tie 'e see that e%en 'ith the
sae n!erical tie %al!es, the difference in real- tie )et'een t'o tie read -
in,s /dependin, on 'hen d!rin, the so called tick period each readin, 'as done0
can )e !p to /)!t not 2!ite0 t'o clock ticks.
• "ched!lin,1 5t can on the other hand also )e the case that the ne' clock tick
ca!ses another thread to )e sched!led and the ne*t readin, takes place one sec
ond later. "o e%en 'ith a a*i! of t'o ticks /2 s0 2!anti@ation error, the
a*i! trend error 'ill )e 0.2W Note a,ain, the act!al sched!le /and there)&
the ret!rned %al!e0 is not e*pressed in the pro,ra; it depends on the s&ste.
• Efficienc&1 (he lon,er e*ec!tion is s!spended )et'een lines + and 4, the )etter
the estiation of a constant trend ,ets
. (he 'aitin, for the second saplin, tie
a)o%e 'as done )& a so called )!s& 'ait. 5n rare sit!ations this 'a& of 'aitin, for
a condition to )e f!lfilled can )e !sef!l, )!t especiall& for lon,er dela&s it ca!ses
efficienc& pro)les /and also response pro)les if real tie is considered0. A )!s&
+ Cor a chan,in, inp!t %al!e, ho'e%er, 'e need a short dela& to ,et a fresh estiation. 5n
real- tie soft'are 'e need to ana,e s!ch trade- offs and prefera)l& e*press the re2!ired
e*ec!tion tiin, in the so!rce code, or 'e ha%e to ipose re2!ireents on the r!n- tie
s&ste. Cor no' 'e onl& deal 'ith tie- dependent soft'are 'hich sho!ld not )e conf!sed
'ith real tie.
3' >eal- (ie Pro,rain, H a .a%a- )ased approach
'ait act!all& asks for 100W of the CP$ tie. A )etter approach 'o!ld )e to in-
for the thread sched!lin, that 'e perit other threads to r!n for a certain peri -
od of tie. (hat is the p!rpose of the sleep ethod treated )elo'.
• (ie- stap deficienc&1 "!spended e*ec!tion /and increentin, tie0 )et'een
lines 2 and +, or )et'een lines 4 and 5, also ca!ses a )ad trend error to )e co-
p!ted. (his holds re,ardless of ho' sall the tie increents are, that is, e%en
'ith the hi,h resol!tion clock entioned a)o%e. Also, if 'e s'ap lines 2 and +,
the pro,ra sho!ld )e the sae fro a se2!ential cop!tin, point of %ie', )!t
d!e to the "&ste call it is not; the t can de%iate in different directions 'hich cre-
ates trend errors in different directions.
(he fact that 'e care a)o!t 'hen an inp!t %al!e 'as sapled can )e looked !pon as
if 'e 'o!ld like to ha%e a tie- staped %al!e. (hat is, the %al!e and the tie of
saplin, it sho!ld )e correctl& packa,ed in a sin,le o)6ect, 'hich the inValue eth -
od /in this case0 sho!ld ret!rn. Cro a soft'are point of %ie' 'e 'ill later 'ork
'ith s!ch o)6ects /of t&pe RTEvent0, )!t creatin, that o)6ect in this e*aple t&picall&
re2!ires nati%e or hard'are s!pport dependin, on the s&ste and its tiin, re-
2!ireents. 5n a p!re .a%a and conc!rrent settin,, soe ipro%eents can,
ho'e%er, )e ade. Cor e*aple the clock can )e read )efore and after saplin,1
long timestamp, t0, t1; float x;
do {
t0 = System.currentTimeMillis();
x = inValue();
t1 = System.currentTimeMillis();
} while (t1-t0 > eps); // eps is small, possibly zero.
timestamp = (t0+t1)/2; // Statistical improvement.
(he disad%anta,e is that on a hea%il& loaded s&ste, 'ith certain sched!lin,, it can
take a 2!ite lon, tie !ntil the do-loop finishes. #iitin, the loopin, )& !sin, a for-
stateent instead 'o!ld )e another sol!tion 'hich can easil& )e accoplished )&
the reader.
Despite the ideal settin, of this e*aple, 'e fo!nd all these pro)les. 9ith eas -
!reent noise and inp!t %al!e 2!anti@ation the sit!ation ,ets e%en ore se%ere.
8& replacin, the coent /*Busy waiting.*/ in the a)o%e e*aple 'ith a call to
sleep(1) /defined in class Thread0, the efficienc& iss!e is sol%ed. (he p!rpose of
sleep is to pro%ide a 'a& of inforin, the sched!ler that other threads a& r!n d!r -
in, that lon, tie fro no', and that the callin, thread sho!ld not )e resched!led
for e*ec!tion 'ithin that tie. 8& callin, for instance sleep/5000, a ini! dis -
crete tie dela& of 500 is o)tained, 'hich eans /d!e to the 2!anti@ation in tie as
descri)ed a)o%e0 a contin!esDreal- tie dela& that is ,reater then /)!t not e2!al to0
4II s.
200E-01-11 15105 © 33
Chapter 3 Multi-Threaded Programming
Ass!e &o! 'ant to do soethin, appro*iatel& e%er& ne' second, s!ch as !pdat -
in, a pro,ress )ar 'hile do'nloadin, a file fro 5nternet. 9e a& ha%e a piece of
code like
long t, t0 = System.currentTimeMillis();
while (!transferFinished()) {
t = System.currentTimeMillis();
displayProgress(t0, t);
5f this code is in a s!)class of Thread, the Thread 2!alification )efore sleep can of
co!rse )e oitted. "ince sleep is a static ethod, it can )e called 'itho!t ha%in,
an instance of a thread o)6ect. 5n fact, e%en if &o! ha%e a thread o)6ect threadOne,
and call threadOne.sleep(1000) fro another thread o)6ect /or an& o)6ect0, the call -
in, thread /i.e., the thread of e*ec!tion, not the thread o)6ect0 'ill )e p!t to sleep
'hile threadOne is not effected. (his is )eca!se sleep first o)tains the c!rrentl& e*-
ec!tin, thread, 'hich &o! can also do )& callin, Thread.currentThread(), and then
that thread /the caller of co!rse0 'ill sleep. 5n other 'ords, Thread.sleep(t) is the
sae as Thread.currentThread().sleep(t), and a thread can p!t itself to sleep
)!t cannot put another thread to sleep. 5f that sho!ld ha%e )een possi)le, certain re-
strictions on r!n- tie s&stes and code optii@ations 'o!ld need to )e iposed,
res!ltin, in decreased /possi)le0 perforance.
Note that sleep(1000) a)o%e does /in ost cases0 not ,i%e an !pdate e%er& second;
the 1000 is a ini! sleepin, tie )!t there is no strict !pper liit. (he act!al
tie )efore e*ec!tion contin!es after sleep t&picall& depends on the processor load.
C!rtherore, the sleepin, for 1000 s is fro the tie that called starts e*ec!tin,
in the .U7 or :" 'ith interr!pts disa)led. An& tie increents )efore then res!lts
in that !ch lon,er period of tie for the !pdate. 7ost often, especiall& in control
applications, it is a periodic )eha%io!r that is desired.
9e ha%e a siilar sit!ation if 'e in o!r e*aple 'ants to call displayProgress
e%er& second. "till 'e do not ipose an& !pper liit on the 'aitin, for each ne'
second /'hich 'o!ld )e a real- tie re2!ireent0, 'e 6!st re2!ire no lon,-ter drift
as lon, as the cop!ter is not peranentl& o%erloaded. (his is accoplished in the
long t, t0, diff;
t = t0 = System.currentTimeMillis();
while (!transferFinished()) {
displayProgress(t0, t);
t += 1000;
diff = t - System.currentTimeMillis();
if (diff > 0) Thread.sleep(diff);
3& >eal- (ie Pro,rain, H a .a%a- )ased approach
Note that t no' is ideal, not reflectin, teporar& e*cessi%e dela&s. (o facilitate i-
pleentation of periodic acti%ities, there sho!ld of co!rse ha%e )een a ethod slee-
pUntil in class Thread, )!t there is not. E%en if it can )e e!lated as sho'n, an in-
creent of the real tie after assi,nent of diff )!t )efore callin, sleep res!lts in
a re2!ested sleepin, tie that is too lon,. (hat does not reall& atter since 'e can
)e dela&ed after the sleepin, an&'a&. /8!t fro a real- tie s&stes point of %ie', it
'o!ld )e prefera)le to correctl& infor the real- tie sched!lin,.0
Race conditions
Kno'in, ho' to create !ltiple threads, let !s ake a !lti- threaded %ersion of the
standard HelloWorld pro,ra. Consider the follo'in, e*aple /'here e*ceptions
ha%e )een oitted for clarit&01
class HelloWorld extends Thread {
public static void main(String[] arg) {
System.out.print("Hello ");
new HelloWorldApp().start();
public void run() {
System.out.print("and goodbye ");
A fe' test r!ns on a 2007<@ Penti!- 77V r!nnin, 9indo's- N(4 ,a%e1
> javac
> java HelloWorld
Hello and goodbye World!
> java HelloWorld
Hello World!
and goodbye
> java HelloWorld
Hello World!
and goodbye
> java HelloWorld
Hello and goodbye World!
<ence, the o!tp!t fro the pro,ra %aries fro tie to tie. 5n ost cases 'e need
a 'ell defined o!tp!t, independent of the tiin,. Cor instance, ?<ello? and ?9orldX?
co!ld correspond to parts of a ticket printo!t and the printin, of ?and ,ood)&e? co!ld
correspond to the res!lt fro a data- )ase access. (hen 'aitin, for the data- )ase re-
s!lt )& callin, sleep(1) clearl& is the 'ron, 'a& of 'aitin, since it akes the cor-
rectness of the o!tp!t dependent on the tiin, of cop!tin, platfor. (he pro)le
200E-01-11 15105 © 3)
Chapter 3 Multi-Threaded Programming
is, ho'e%er, that de%elopin, and testin, the application on one t&pe of achine does
not ipl& correct o!tp!t on another /c!stoer0 achine. 5n partic!lar, if the a -
chine is a ro)ot or a %ehicle /instead of a desktop cop!ter0, 'e certainl& need addi -
tional r!les for ho' to pro,ra.
Note that e9en if .e .ould %no. the properties of the e*ec!tion en%ironent
/:", CP$- t&pe, clock fre2!enc&, speed and ao!nt of eor&, other applications,
le%el of patches or ser%ice packs, etc.0, and testin, %erifies the correctness of the
system3 the pro1ram as such is not correct fro a conc!rrenc& point of %ie'.
Scheduling – Priorities
(he n!)er of conc!rrentl& e*ec!tin, acti%ities /threads or processes0 is in practice
al'a&s ,reater than the n!)er CP$s a%aila)le, 'hich iplies that all 'ork cannot
)e 'orked on iediatel&. (he s!pport for conc!rrent e*ec!tion /!lti threadin,
etc.0 sol%es this pro)le, if 'e ha%e no deands on tiel& response. 5n other 'ords,
for p!rel& conc!rrent soft'are, 'e can let the r!n- tie s&ste sched!le o!r acti%it -
ies in an& feasi)le 'a& that lets all acti%ities r!n. <o'e%er, if the application re-
2!ires certain response ties or perforance, in partic!lar 'hen the CP$ load is
hi,h, 'e a& need to tell the r!n- tie s&ste /that is, the sched!ler0 'hat 'ork
sho!ld )e done first, and 'hat acti%ities that can 'ait.
Consider the /so far ost coon0 case 'ith a sin,le processor, and copare 'ith
e%er&- da& life at hoe, in school, or at 'ork. 8ein, 6!st one person )!t 'ith an&
thin,s to )e done, is a sit!ation that all readers sho!ld )e failiar 'ith. People dif-
fer in their principles of ='hat to do first=; the& are !sin, different sorts of sched!l -
in,. (he sae applies to operatin, s&stes. 5n )oth 'orlds, the 'a& of selectin,
='hat to do ne*t= is closel& related to the e*ternall& e*perienced properties of the
personDs&ste. Doin, the ri,ht thin, first is often ore iportant than doin, it in a
s!perior 'a&.
Cor no', 'e restrict the disc!ssion to a sin,le !lti- threaded application r!nnin,
on one .U7. Cor e)edded cop!ters, that corresponds to the soft'are r!nnin, on
one processor, not necessaril& !sin, a .U7 since cross copilation is often ore effi-
cient )!t fro a pro,rain, point of %ie' that does not atter. (h!s, 'e need
soe ethod to infor the sched!lin, /in the :", >(:", kernel, or .U70 a)o!t the
preferences of o!r application.
Expressing importance
5n a copan& &o! a& hear thin,s like1 ?(his is a hi,h priorit& pro6ect...?, ?9e ha%e
to p!t priorit& on...?, or ?(hat )!, has to )e fi*ed, 'ith the hi,hest priorit&.?. #ike-
'ise, the )& far ost coon 'a& to infl!ence the sched!lin, in operatin, s&stes
is %ia priorities. "ince .a%a is desi,ned to )e porta)le, pro%idin, the a)ilit& to set
priorities on threads is a nat!ral and !nderst anda)le choice.
5n the java.lang.Thread class there are set- and get-ethods for the priorit& of
the thread. Additionall&, there are three inte,er constants naed MIN_PRIORITY,
3* >eal- (ie Pro,rain, H a .a%a- )ased approach
NORM_PRIORITY, and MAX_PRIORITY, 'hich can )e !se to set t&pical le%els of ipor -
tance. (he act!al %al!es of these constant s are not defined and the n!)er of priori -
t& le%els are not defined either in the .a%a specification; &o! can onl& ass!e that
MIN_PRIORITY < NORM_PRIORITY < MAX_PRIORITY. (he rest is !p to each platfor
and .a%a ipleent ation. :n, for instance, "olaris the constants ha%e %al!es 1, 5,
and 10 respecti%el&. (h!s, a hi,her n!)er eans a hi,her priorit&. A ne' thread
)& defa!lt ,ets the priorit& NORM_PRIORITY )!t that is not re2!ired in an& standard.
A thread created in a Applet, or the ain thread of the applet, can onl& ,et priori -
ties in the ran,e 1 to E as defined for that ThreadGroup /refer to the .a%a AP5 doc!-
entation, thread ,ro!ps are oitted here0 'hich is to ens!re that the host applica -
tion r!nnin, the applet /t&picall& the 'e) )ro'ser0 'ill not )e disa)led /star%ed in
ters introd!ced later0 )& an applet cons!in, all of the CP$ po'er.
(he lack of a 'ell defined eanin, of priorities in .a%a a& ,i%e the ipression that
the& are alost !seless. 9e sho!ld, ho'e%er, )e a'are of1
1. (he correctness of o!r soft'are, e*cept for tiin, 'hich is 'hat priorities are for,
sho!ld ne%er depend on priorities. Cor instance, it sho!ld )e considered as an er -
ror to accoplish !t!al e*cl!sion )& !tili@in, the kno'led,e that one thread
'ill ha%e a hi,her priorit& than another. E%en if that al'a&s is the case, there is
no ,!arantee that priorities are strictl& o)e&ed on all platfors. (hat is, !sin, an
>(:" a hi,her priorit& thread al'a&s ,i%en precedence in fa%or of a lo' priorit&
thread, )!t on "olaris, #in!*, 9indo's, and other desk- top and ser%er platfors,
&o! cannot kno'. (hose t&pes of s&stes are optii@ed for o%erall perforance
and can in principle not )e tr!sted for hard real- tie s&stes. "o, if e)edded
soft'are re2!ires a certain >(:" an&'a&, additional re2!ireents on the n!-
)er of priorities etc. ,o alon, the the s&ste re2!ireent s. "till, the lo,ical and
conc!rrent )eha%ior of the s&ste sho!ld reain on an& .a%a- ena)led platfor.
2. An application that depends on sched!lin, principles and the n!)er of priorit&
le%els can o)tain the t&pe of :" /callin, System.getProperty("");0 and
other properties at r!n tie, and )eha%e accordin,l&. A :"-dependent )!t
porta)le application sipl& has to cope 'ith realit&.
+. Priorities are ana,ed ,lo)all& for the soft'are application and the& infl!ence
the ,lo)al properties of the s&ste. <o'e%er, a certain thread created in a class
li)rar& or in a third- part& coponent too often ,ets a /!s!all& hard- coded0 priori -
t& that does not s!it the rest of the s&ste. C!rt herore, the desired s&ste
properties are not necessaril& eas& to e*press !sin, priorities. >esponse tie,
control perforance, 2!alit& of ser%ice, etc. are ore related to end- !ser %al!es.
:)tainin, priorities fro s!ch properties is o!tside the scope of this chapter. An-
other approach 'o!ld )e to ha%e a real- tie platfor 'ith )!ilt- in tiin, andDor
perforance optii@ation, perhaps not !sin, priorities at all. (he classical ap-
proach, fo!nd in alost an& :" is to !se priorities, and that is also 'hat .a%a
pro%ides. (he a)ilit& to r!n the soft'are on an& .a%a platfor is a !st. (here -
fore, additional s!pportin, classes are needed for ipleentation of real- tie
s&stes, )!t for no' 'e sta& 'ith !lti- threaded pro,rain, and the standard
200E-01-11 15105 © 3,
Chapter 3 Multi-Threaded Programming
and porta)le .a%a feat!res.
(he concl!sion is that priorities, as defined in .a%a, are !sef!l for siple t!nin, of
application perforance and responsi%eness, )!t for lar,e- scale real- tie s&stes
'e need additional s!pportin, classes )!t that is a later iss!e.
Thread interruption and termination
(here is !ch to sa& a)o!t thread terination, )!t in short there are soe siple
r!les to follo'1
1. 7eturn from the run method termi nates the thread . After the r!n ethod
/'hich 'as called )& the thread0 ret!rns or r!ns to its end, control is )ack into
the s&ste call that started the thread /d!e to the call of start0. (hat call then
copletes )& terinatin, the thread. (hereafter, callin, the isAlive of the ter -
inated thread o)6ect ret!rns false.
2. 5f one thread 'ants to termi nate another thread , that other thread has to )e
prepared to coit s!icide. "ince there is no predefined ethods for doin, this, it
has to )e accoplished )& the pro,raer, either by chan1i n1 soe state %ari -
a)le /s!ch as a fieldDatt ri)!te naed terinate0, or by interrupti n1 the thread
'hich then /by con9enti on 0 kno's that it sho!ld die 'hene%er interr!pted.
+. (he interr!pt ethod is called in the anner 3otherThread.interrupt();4 to in-
terr!pt another thread. <o'e%er, !nlike hard'are interr!pts, the other thread is
not reall& interr!pted; it conti nues its executi on as !s!al, e*cept that a pre -
defined internal state %aria)le has re,istered the interr!pt re2!est.
4. Each thread that sho!ld )e possi)le to interr!pt has to e*plicitl& test if it has
)een interr!pted. Cor this p!rpose, there is a static ethod Thread.interrupted
() that ret!rns true if interr!pt has )een called for the c!rrentl& r!nnin, thread.
Note that this ethod also clears the interr!pt fla,. (o check if another thread
/i.e., not the c!rrentl& r!nnin, one0 has )een interr!pted, isInterrupted() has
to )e called for that thread ob9ect. (hat does not effect the interr!pted stat!s.
5. 5f a thread 'as interrupted .hen bloc%ed on a )lockin, s&ste call, s!ch as
sleep, it is sched!led iediatel& for e*ec!tion )!t thro'in, an InterruptedEx-
ception. 5n this case the interr!pted fla, is not set, )!t )& catchin, the Inter-
ruptedException 'e can deterine that the thread 'as interr!pted. (h!s, it is
the e*ec!tion of the catch cla!se that tells that the thread 'as interr!pted, and
the e*ception handlin, decides if the thread sho!ld res!e its 'ork or terinate
/)& ret!rnin, fro run0.
E. 5n accordance 'ith the pre%io!s ite, if a thread alread& has )een interr!pted
'hen a s&ste call /that thro's InterruptedException0 is iss!ed, the e*ception
is thro'n iediatel& 'itho!t )lockin,.
D!e to these r!les, the standard 'a& of ipleentin, a thread is to ha%e a r!n
ethod lookin, like1
30 >eal- (ie Pro,rain, H a .a%a- )ased approach
public void run() {
while (!isInterrupted()) { // !interrupted() OK in most cases.
// here is where the actual code goes....
} // End of life for this thread.
After the loop, isInterrupted can )e !sed to check ho' the loop 'as e*ited. 5nstead
of terinati n, after an interr!pt, &o! can ha%e an o!ter loop to restore the state and
contin!e e*ec!tion. Additionall&, &o! a& need to catch InterruptedException, or
other Throwable o)6ects s!ch as those of t&pe Error, either o!tside the 'hile loop
a)o%e or at se%eral places inside that loop dependin, on the code. Note, ho'e%er, &o!
sho!ld norall& not try to catch and recover from an InterruptedException thro'n
fro a )lockin, call that ha%e to do 'ith access or allocation of shared
reso!rcesDdata, if reso!rces are not left in a consistent state /)ank transaction not
half ade, etc.0. 9hen res!in, noral operation after s!ch a call has )een inter -
r!pted, there is a )i, risk that e*ec!tion contin!es as if reso!rces 'here locked e%en
if that is not the case. <a%in, each ethod to pass the e*ception /instead of catchin,
it locall&0 to the caller, )& appendin, thro's InterruptedException to its si,nat!re,
esses !p the code too !ch. 5n practice, the res!lt is often ept& catch- cla!ses
'ith an intention to add the code later, 'hich then ne%er is done and the application
silentl& copiles and r!ns, )!t interr!ptin, it a& res!lt in disaster. (he reco-
ended approach therefore is to al'a&s con%ert an InterruptedException to an Er-
ror. Cor this p!rpose, 'e 'ill later !se the class RTInterrupted 'hich is a s!)-
class of Error 'ith soe enhanceents1
try {
argout = methodThrowingInterruptedException(argin);
} catch (InterruptedException exc) {
throw new RTInterrupted(exc.toString());
'hich eans that the ethod containin, the a)o%e code is not defined to thro' an&
InterruptedException, and the caller/s0 of that ethod do not need to )e cl!ttered
'ith try-catch cla!ses. >ecall that the intended !se of the Error class is for thro'-
in, se%ere e*ceptions that the !ser is not e*pected to catch, )!t heDshe can catch
the if that is needed. <ence, thro'in, an error 'hen a reso!rce allocation re2!est
is interr!pted a,rees 'ell 'ith the .a%a AP5 con%entions.
A different case is 'hen an independent se2!ence of operations is to )e interr!pted.
"e2!encin, on an application le%el /that is, ad%ancin, the state of the application,
not carin, a)o!t ad%ancin, the pro,ra co!nter for each instr!ction0 is t&picall&
done )& 'aitin, for tie to pass, or on certain conditions to )e tr!e. 5nterr!pti n,
s!ch a thread, and lettin, the interr!pted thread handle the ExceptionDError, can
)e a perfectl& accepta)le thin, to do1
• 5f the interr!pted se2!ence is a 'e)-ser%er transaction, closin, files and ret!rn -
in, an& reso!rces in their initial state sho!ld )e possi)le and strai,ht for'ard.
200E-01-11 15105 © 32
Chapter 3 Multi-Threaded Programming
• 5f the operation of an ind!strial ro)ot is interr!pted )eca!se it detects a h!an
'orker 'ithin its 'orkin, ran,e, on,oin, otions ha%e to stop )!t the 'ork- piece
sho!ld not )e dropped, 'hich re2!ires en,ineered e*ception handlin, and not
sipl& terination of the thread.
"till, it is )etter to thro' an Error 'hich is !ch ore likel& to reach the o!ter le%-
el of error handlin, despite =la@&= /or =too )!s&=0 pro,raers. Do like in the code e*-
aple a)o%e.
"ince interr!pt is ore of an order to coit s!icide than act!all& interr!ptin,, the
interr!pted thread a& contin!e for 2!ite a 'hile )efore it is terinatedDdead. 5t is
soeties !sef!l to kno' 'hen the thread reall& has stopped its e*ec!tion. (hat is
done )& callin, the isAlive ethod of the thread o)6ect. A li%e thread o)6ect is 'hat
'e call an active ob9ect.
Notice that e%en if a thread has terinated, the o)6ect as s!ch reains /as the re-
ains 1-0 )!t after terination, e%en 'hen isAlive ret!rns false, it cannot )e
)ro!,ht )ack to life )& callin, start a,ain. (h!s, a thread ob5ect can only be star $
ted once . <o'e%er, tr&in, to restart a terinated thread is silentl& accepted 'ith
no errors or e*ceptions; &o! ha%e to keep track of the thread stat!s &o!rself.
5f callin, isAlive ret!rns tr!e, the thread 'as ali%e at the tie of the call )!t it
co!ld )e dead ri,ht after if it 'as 6!st a)o!t to terinate; 'e 'o!ld need to lock the
o)6ect and check )oth ali%eness /%ia isAlive0 and terination stat!s /as deterined
)& isInterrupted and !ser code0 if 'e need to )e s!re that the thread still is r!n -
nin, /acceptin, ne' orders etc.0. 5f callin, isAlive ret!rns false, the thread either
has not )een started, or it has terinated. 5f a call of start res!lts in isAlive re-
t!rnin, true, it 'as not started. :ther'ise, it 'as terinated.
Po! norall& do not call isAlive )eca!se norall& a thread is started ri,ht after
the thread o)6ect 'as created, and if &o! need to a'ait the thread terination &o!
prefera)l& s!spend e*ec!tion !ntil that happens /not 'astin, CP$- tie on pollin,
the ali%eness stat!s0. Cor this p!rpose, there is a ethod join 'hich )locks the
caller !ntil isAlive of that thread o)6ect ret!rns false. Details1
• Callin, join of a thread o)6ect 'hich alread& has terinated sipl& ret!rns
'itho!t )lockin,.
• A thread o)6ect callin, its o'n join ethod /that is, this.join() or current-
Thread().join()0 'ill p!t itself into a state that 'e co!ld call =coa=; ali%e sleep-
in, !ntil the death, !nless interr!pted 'hich 'ill perit reco%erin,.
• .oinin, a thread o)6ect that has not )een started ret!rns directl& /'itho!t errors0
since it is not ali%e /&et0.
&6 >eal- (ie Pro,rain, H a .a%a- )ased approach
5n practice, in &o!r o'n code if &o! are a'are of the liitations, thread terination
is not a pro)le. (o specif& a tie- o!t for 6oinin, a thread, there are %ersions of 6oin
'ith tie- o!t ar,!ents.
Inappropriate thread methods
Aon, the !sef!l and 'ell desi,ned ethods of class Thread, there are also soe
=feat!res= that rese)les =)!,s= and sho!ld )e a%oided.
Cirst there is a ethod destroy 'hich is s!pposed to act!all& interr!pt and kill the
thread. <o'e%er, allocated reso!rces co!ld then not )e ret!rned since that /for r!n-
tie reasons0 has to )e done )& the thread that is ,oin, to )e killed. "ince destroy
ost likel& 'o!ld lea%e the application in a )adl& 'orkin, state, it sho!ld not )e
called. 5t is e%en 'ritten in the .a%a2 doc!entation1 3(his ethod is not iple -
(here is also a ethod stop 'hich in the .a%a2 AP5 doc!entation is descri)ed as
?inherently unsafe ..." potentially resulting in arbitrary behavior ?. 5ts p!rpose isD'as
to force the thread to stop e*ec!tin,. 5t is !nsafe for the sae reasons as destro& is.
Act!all& callin, stop 'ill perit soe clean!p and ret!rn of reso!rces to )e done,
)!t that e*hi)its !ndefined tiin, and reso!rce ana,eent on the !ser le%el can-
not /in practice0 )e handled in a s&ste ro!tine s!ch as stop.
5n the )e,innin, of the real- tie pro,rain, s!)6ect, st!dents often 'ant to !se
soethin, like stop /or e%en destroy0 instead of dealin, 'ith act!al e*ec!tion and
:" properties. 5t is hard to !nderst and 'h& the .a%a en,ineers @s! intro -
d!ced stop in the first place.
Cinall&, there are t'o ethods that co!ld ha%e )een !sef!l if desi,ned properl&1
suspend and resume . (he pro)le is that, as their naes s!,,est, s!spendin, and
res!in, e*ec!tion 'as accoplished as a echanis 'ell separated fro the ordi -
nar& thread ana,eent. 9ith t'o !nrelated 'a&s of s!spendin, e*ec!tion, there
'as a )i, risk for a set of threads to )e /dependin, on tiin,0 peranentl& )locked.
(hese ethods and their deficiencies are o!tside the scope of this te*t.
The Thread class
9e are no' read& to s! !p the content of class lava.lang.Thread 'hich in a a)-
)re%iated for can )e e*pressed as sho'n )elo'/all sho'n e)ers are p!)lic
'hich is oitted, and deprecated ethods are not sho'n0. (he task to )e carried o!t
)& the thread is ipleented in the r!n ethod, either )& s!)classin, Thread or )&
ipleentin, the Runnable interface 'hich sipl& states the presence of the r!n
public interface Runnable {
void run();
9hen ipleentin, Runnable &o! need to call Thread.currentThread() to ,et to
the p!)lic non- static ethods of class Thread, 'hich in short incl!des the follo'in,1
200E-01-11 15105 © &1
Chapter 3 Multi-Threaded Programming
public class Thread implements Runnable {
static int MAX_PRIORITY; // Highest possible priority.
static int MIN_PRIORITY; // Lowest possible priority.
static int NORM_PRIORITY; // Default priority.
Thread(); // Use run in subclass.
Thread(Runnable target); // Use the run of 'target'.

void start(); // Create thread which calls run.
void run() {}; // Work to be defined by subclass.
static Thread currentThread();// Get currently executing thread.
void setPriority(int pri); // Change the priority to 'pri'.
int getPriority(); // Returns this thread’s priority.
static void sleep(long t); // Suspend execution at least 't' ms
static void yield(); // Reschedule to let others run.
void interrupt(); // Set interrupt request flag.
boolean isInterrupted(); // Check interrupt flag of thread obj.
static boolean interrupted(); // Check and clear for current thread.
boolean isAlive(); // True if started but not dead.
void join(); // Waits for this thread to die.
void join(long t); // Try to join, but only for 't' ms.
Note that the (hread class does not relate to real tie. 5nstead, the real- tie clock
is, as entioned, o)tained )& callin,
'hich ret!rns the %al!e of the real- tie clock as a long e*pressed in illiseconds.
(he reader a& cons!lt the .DK class doc!entation for f!rther inforation.
3.2 Resources and mutual exclusion – Semaphores
"eaphores are of interest as a )asic echanis that is a%aila)le in one for or an -
other in all /M0 operatin, s&stes and real- tie kernels. 5n soe ind!stri al s&stes,
the onl& a%aila)le echanis is seaphores, on 'hich other concepts co!ld )e )!ilt.
Also historicall&, the seaphore 'as the first /introd!ced )& Di6kstra in 1IEG0 prin -
ciple for efficientl& handlin, !t!al e*cl!sion and s&nchroni@ation , sol%in, pro)les
s!ch as the )ank acco!nt transactions descri)ed earlier.
A Semaphore is a echanis that can )e !sed for ipleent ation of the f!nda -
ental a)stractions sho'n in the pre%io!s chapter. "!ch a echanis re2!ires cer -
tain feat!res fro the operatin, or r!n- tie s&ste, and cannot )e p!rel& iple -
&' >eal- (ie Pro,rain, H a .a%a- )ased approach
Resources and mutual exclusion – Semaphores
ented in, for instance, .a%a 'itho!t help fro nati%e s&stes calls. (herefore, the
seaphore methods 'e are a)o!t to introd!ce should be considered as system calls
/part of the operatin, or r!ntie s&ste0 'ith certain properties, not to )e conf!sed
'ith ordinar& ethods that can )e ipleented on the .a%a le%el.
9e a&, on the other hand, )e a)le to ipleent seaphores in .a%a if 'e can !se
soe )!ilt- in or nati%e .a%a feat!re /s&nchroni@ed ethods in this case0 to acco-
plish s!spension of e*ec!tion !ntil certain conditions are f!lfilled. Alternati%el&,
soe 'a& of ipleentin, atoic ethods co!ld )e a%aila)le /s!ch as nati%e eth -
ods for disa)lin, and ena)lin, interr!pt s0. An atoic ethod is a ethod that can-
not )e interr!pted )& e*ec!tion of other parts of the soft'are. An&ho', no atter
ho' 'e ipleent seaphore echanis, nati%el& or )!ilt on soe .a%a feat!re,
'e think of the ethods as atoic and 'ith properties accordin, to the se2!el.
Semaphore methods
>ecall that seaphores are the priar& echanis in an& sall e)edded s&s -
tes, so 'e need seaphore classes that odel the seaphore concept and s!pports
cross copilation to nati%e code. #inkin, 'ith nati%e ipleent ations of
seaphores as pro%ided in ost real- tie kernels then perits f!ll efficienc& also
'hen special hard'are is !sed. (o this end, let !s first st!d& the concept and then
look into the ipleent ation.
Core operations
A seaphore is )asicall& a non- ne,ati%e inte,er- %al!ed co!nter 'ith t'o atoic
ethods and a 2!e!e for )lockedD'aitin, threads. (he ethods /'ith ret!rn t&pe
void0 are1
decreents the co!nter if it is positi%e, )!t if the co!nter is @ero, e*ec!tion of
the caller is s!spended and that thread is p!t in soe kind of 2!e!e 'aitin,
for the co!nter to )ecoe positi%e. <ence, an operation that increents the
co!nter !st check the 2!e!e and 'ake !p the first thread.
increents the co!nter and checks if there are an& threads 'aitin, in the
2!e!e. 5f so, a thread is ade read& for e*ec!tion, 'hich can res!e 'hen the
caller of ,i%e has copleted its /atoic0 call of give.
Apart fro soe initiali@ation of the co!nter 'hen the seaphore is createdDinitial -
i@ed, these t'o ethods are the onl& t'o ethods a%aila)le accordin, to the ori,inal
definition. 9hen a )locked thread is placed in the 'aitin, 2!e!e depends on the
sched!lin, of that partic!lar r!n- tie s&ste. Norall&, threads are ordered ac-
cordin, to priorit&, and e2!al priorit& threads are placed in the order the& arri%ed
200E-01-11 15105 © &3
Chapter 3 Multi-Threaded Programming
Supporting timeout
5n addition to the core ethods, for con%enience, the follo'in, ethod /ret!rn t&pe
boolean0 is also defined1
tryTake(long timeout)
(he sae as take, )!t the caller ,i%es !p takin, the seaphore after timeout
illiseconds. 5f the seaphore 'as taken, true is ret!rned. :ther'ise false
is ret!rned.
$sin, this ethod re2!ires soe care. Cirst, there is no ,!arantee that the caller is
!n)locked e*actl& after the timeout tie, it can )e later /)!t not earlier0. (he re-
lease tie a& depend on 'hat other threads that ha%e iss!ed )lockin, calls 'ith
tieo!ts, the CP$ load, etc. (h!s, the sae t&pe of pro)les as 'ith the Thread-
.sleep ethod.
"econdl&, the ret!rned )oolean %al!e !st )e taken care of /'hich is not checked )&
the copiler in .a%a, 6!st like in CDCJJDCK0. 5f false is ret!rned, perhaps after a lon,
tie of operation, and not considered d!e to a pro,rain, error, shared reso!rces
can )& accident )e accessed 'itho!t !t!al e*cl!sion. (he nae tryTake, instead of
o%erloadin, on take for instance, is selected to ephasis the characteristics of the
Cinall&, consider if &o!r desi,n is ri,ht if &o! !se the tryTake operation. 5t sho!ld )e
!sed instead of ipleentin, additional tier threads, )!t not for c&clic pollin, of
the seaphore %al!e. "oe s&stes pro%ide a 'a& of pollin, the %al!e 'itho!t act! -
all& tr&in, to take the seaphore. "ince s!ch a ethod easil& co!ld )e is!sed )&
!nskilled pro,raers, s!ch a ethod is not pro%ided here.
Semaphores in other systems
9hen proposed )& Di6kstra, the ori,inal nae of the take operation 'as P, fro the
D!tch 'ord Passeren, referrin, to the sit!ation that the thread 'ants to Pass. (he
ori,inal nae of the ,i%e operation 'as U, fro Uri6,e%en, referrin, to the release
/=free-,i%in,=0 of the reso!rce. (he naes P and U are still !sed in an& s&stes to-
(he ost coon naes for take and ,i%e are 'ait and si,nal, respecti%el&. (hese
naes are ore e*pressi%e and relates 'ell to the En,lish ters !sed for railroad
seaphores. (he seaphore concept act!all& ori,inates fro railroad traffic, 'here
the tracks are the reso!rces. As 'e 'ill see later, 'ait is not a !sef!l nae for a
seaphore ethod in .a%a since it alread& is a final ethod /'ith another eanin,0
in class :)6ect.
#ookin, for appropriate naes for the seaphore operations, the )est choice /ac-
cordin, to the a!thor0 'as fo!nd in U*9orks, a a6or >(:" fro 9ind>i%er "&s -
tes 5nc. (hat C-)ased AP5 contained the f!nctions sem_take and sem_give, )oth
takin, a pointer to the seaphore data str!ct!re as an ar,!ent. 5n o)6ect oriented
ters, the ar,!ent is the o)6ect /the so called this pointer naed as the o)6ect0,
sem is the nae of the class, and the _ )& con%ention corresponds to ethod selec-
&& >eal- (ie Pro,rain, H a .a%a- )ased approach
Resources and mutual exclusion – Semaphores
tion in the ,lo)al naespace in C.
Correspondin,l&, the tryTake ethod is a%aila)le in soe s&stes, and if not, it can
al'a&s )e ipleented !sin, an e*tra /tier0 thread. (&picall&, there is one tier
thread ser%in, all tieo!t re2!ests.
Using semaphores
(he /atoic0 seaphore ethods can )e !sed in different 'a&s to sol%e conc!rrenc&
pro)les, or seaphores can )e !sed to create other a)stractions. #et !s therefore
re%ie' soe ,eneric sit!ations 'hen seaphores can )e !sed. (o ill!strate the se-
2!encin, and )lockin, that takes place 'hen threads call the seaphore ethods,
'e !se an $7# /or :7(0 )ased notation, 'ith soe e*tra s&)ols to ephasi@e the
conc!rrenc& and )lockin, iss!es. Ci,!re +-1 e*plains the notation !sed.
(he co!nter contained in the standard t&pe of seaphore, accordin, to the descrip -
tion a)o%e, is ainl& !sef!l for si,nalin,. (hat is, 'hen one acti%it& has soe res!lt
or reso!rce read& for !se )& soe other acti%it&, the prod!cin, thread si,nals to the
cons!in, thread. 5f the prod!cer si,nals /callin, give0 se%eral ties )efore the
cons!er 'aits /callin, take0, the 3non-ne,ati%e inte,er- %al!ed co!nter4 contained
in the ordinar& t&pe of co!ntin, seaphore res!lts in that take needs to )e called as
an& ties as give has )een called. 5n other 'ords, the co!nter coprises a eo-
r& 'hich iplies that si,nalin, in ad%ance is not for,otten. Ci,!re +-F sho's ho' a
thread (1 si,nals to a thread (2; (1 can r!n in ad%ance 'hereas (2 can catch !p
'ith earlier calls of give )!t (2 ne%er r!ns in ad%ance of (1. (his t&pe of
seaphore is referred to as a counting semaphore.
"oeties 'e do not 'ant the si,naled thread, (2 in this case, to catch !p 'hen
give has )een called !ltiple ties. (hat can )e accoplished )& !sin, a boolean
instead of a co!nter as the state %aria)le of the seaphore. (hat corresponds to the
co!nter )ein, one )inar& di,it, and s!ch a seaphore is therefore !s!all& called a
binary semaphore.
A less !s!al t&pe of seaphore is the multistep semaphore, 'hich is !sef!l 'hen 'e
'ant s!ccessi%e calls of take to )e atoic. Cor instance, a prod!cin, thread si,nals
'hene%er a )&te of data is p!t in a )!ffer, )!t the cons!in, thread is readin, a
!nicode /t'o )&tes per character0 strin,. 9e then 'ant to call take(2) to onl& ,et
200E-01-11 15105 © &)
Figure 3-1 Symbols used for the .1:L- O:T+ based but enhanced/ se3uence dia +
: Executing
: Potential blocking
: Blocked
(active obj.)
(passive obj.)
Chapter 3 Multi-Threaded Programming
!n)locked 'hen there are t'o )&tes a%aila)le. :ne can al'a&s sol%e the pro)le
'itho!t s!ch a !ltistep feat!re, )!t !sin, a !ltistep seaphore can )e ore con-
%enient and efficient.
Mutual exclusion
Perhaps the ost 'ell-kno'n !sa,e of seaphores is for !t!al e*cl!sion. An& of
the seaphore t&pes !sed for si,nalin, can )e !sed for !t!al e*cl!sion, )!t there
are reasons for pro%idin, a special mut ual exclusion semaphore. "!ch a seaphore
is soeties referred to as a =!te*=. 9e 'ill call it a mute* semaphore. As depicted
in Ci,!re +-+, the %er& sae thread that has called mutex.take(), thereafter ha%in,
e*cl!si%e access to the shared data , sho!ld call mutex.give() 'hen the critical sec-
tion is left. An& one acti%it& not follo'in, this protocol, for instance )& callin, give
&* >eal- (ie Pro,rain, H a .a%a- )ased approach
Figure 3-3 Se3uence diagram showing two threads .T! and T'/ using a semaphore
.mute*/ for mutually e*clusive access to some shared resource. )n this case
T! happens to be the first to take the semaphore" resulting in T' being
blocked while T! is in the critical section.
mutex T1 T2
Figure 3-2 4 thread T! signaling to thread T' via a counting semaphore. The counter
is assumed to be initiali6ed to 6ero" resulting in the first call of take
blocking its caller. 2or each give" one take can be called without blocking.
signal T1 T2
Resources and mutual exclusion – Semaphores
one e*tra tie )efore take, 'o!ld daa,e the 'hole application. (herefore, it is a
,ood idea to ha%e a dedicated !te* seaphore class, in 'hich the take sa%es a ref-
erence to the c!rrentl& e*ec!tin, thread /enterin, the critical section0 and give
checks that the caller is the sae thread /lea%in, the critical section0. :f co!rse, one
co!ld ia,ine sit!ations 'hen the !nlockin, sho!ld )e taken care of )& another
thread, 6!st like a person lockin, a roo co!ld hand o%er the ke& o soeone else
that takes care of !nlockin,, )!t that is sipl& not peritted.
Another )enefit 'ith distin,!ishin, !te* seaphores fro si,nalin, ones is to in-
for the r!n- tie s&ste /incl!din, the sched!ler of thread e*ec!tion0 that a call of
take eans lockin, a reso!rce. (hat inforation can then )e !sed /as 'e 'ill see in
Chapter 40 to ipro%e response ties.
D!rin, the 1IG01s there 'as a de%elopent to'ards a !nifor s&nchroni@ation
priiti%e called rende@%o!s, 'hich is Crench and eans soethin, like =,ettin, to-
,ether at a eetin, point=. 5t 'as in the Ada lan,!a,e standard in 1IG+ that ren -
de@%o!s 'as defined as the ,eneral s&nchroni@ation echanis. 9ith lan,!a,e s!p -
port for (asks /acti%e o)6ects 'ith )!ilt- in !t!al e*cl!sion0 that co!nicate s&n-
chrono!sl& /i.e., !sin, rende@%o!s0, the intention 'as to force conc!rrent real- tie
soft'are to )e 'ritten in s!ch a 'a& that is 'as read& for distri)!tion o%er se%eral
processors. <o'e%er, soe applications are ore coplicated to ipleent !sin,
rende@%o!s, or re2!ires ore conc!rrent acti%ities /there)& also decreasin, perfor -
ance0 than if other echaniss are !sed. (herefore, and perhaps d!e to pro,ra -
er preferences, the ore recent AdaI5 standard also s!pports s&nchroni@ed eth -
ods siilar to 'hat 'e ha%e in .a%a. "till, rende@%o!s is !sef!l 'hen data is to )e
handed o%er fro one thread to another. (hat is, not onl& transferrin, data )et'een
the thread o)6ects /'itho!t )!fferin,0, )!t also akin, s!re that the recei%in,
thread of e*ec!tion has arri%ed in a state 'here the data has )een accepted.
200E-01-11 15105 © &,
Figure 3-4 ,ende6vous accomplished by two .signaling/ semaphores. Synchroni6ation
takes place in the interval marked s&nc.
exit T2
T1 entry
Chapter 3 Multi-Threaded Programming
Ci,!re +-4 ill!strat es the rende@%o!s concept and ho' to ipleent it !sin,
seaphores. Note that (1 is )locked d!rin, s&nchroni@ation 'hen onl& (2 accesses
the shared data. (he =s&nc.= inter%al for (2 therefore corresponds to a critical sec-
tion, and (2 a& not !se the shared data )efore entry.take and after exit.give.
Cor (1 on the other hand, shared data a& )e anip!lated !ntil entry.give is
called /'hich is to )e directl& follo'ed )& exit.take0 and after /)lockin, ends after0
exit.take. (h!s, (1 is so to sa& in the critical section all the tie, )!t )locked 'hen
co!nication takes place. "ince interaction 'ith (2 is re2!ired )efore (1 can pro-
ceed, it is eas& to ia,ine sit!ations 'hen the !se of rende@%o!s as the onl& ean
for s&nchroni@ation ,ets cl!s&.
Metaphors for semaphores
9ith the seaphore classes a%aila)le, one has to keep in ind 'hen to !se 'hat
class /seaphore !se cases0. 5t is then !sef!l to ha%e soe ental pict!re of ho' the
different seaphore classes are to )e !sed. "ince seaphores /in real life0 historical -
l& coe fro railroad traffic, a train control e*aple 'ill )e !sed. Note, ho'e%er,
that this has %er& little to do 'ith railroad seaphores as s!ch; it is onl& o!r
seaphore classes !sed in a railroad conte*t.
5n Ci,!re +-5 there is a seaphore mutex !sed to ha%in, onl& one train at a tie on
the track for !nloadin, /shared reso!rce0, and there is a seaphore signal !sed for
si,nalin, the a%aila)ilit& of ites in the )!ffer )et'een the track for !nloadin, and
loadin,. (he /passi%e0 )!ffer perit the /acti%e0 trains to access the ites indepen -
dentl& /as&nchrono!sl&0 of each other, as lon, as the )!ffer is not ept&. (he @one to
the lo'er ri,ht, on the other hand, pro%ides no s!ch interediate stora,e; )oth
trains ha%e to )e there to perit ites to )e transferred fro one train to another,
&0 >eal- (ie Pro,rain, H a .a%a- )ased approach
Figure 3-5 ,ailroad tracks seen from above" illustrating semaphore usage. The name
of the semaphores refer to the semaphore figures earlier in this section. The
Buffer is a place for storage" permitting one train to unload and contin +
ue before the ne*t train arrives for loading. )n the lower right 6one there is
no such buffer .or intermediate passive ob9ect/ so loading has to be done
directly from one train to another" which corresponds to the synchronous
mechanism of rende6vous.
Industrial track (resources handled along the line)
Track for loading
Track for unloading (incoming trains mutual exclusive)
entry exit
Wagon to wagon zone
Resources and mutual exclusion – Semaphores
'hich corresponds to rende@%o!s ipleented )& the seaphores entry and exit.
5n ore detail, trains on the ind!strial track ha%e access to reso!rces alon, the
track )!t 'hen reachin, the transfer @one it ,ets )locked !ntil the other train is on
the ad6acent track. (he train enterin, the @one for !nloadin, /coin, fro the track
for loadin,0 also has to 'ait !ntil the other train is there.
<ence, in ters of soft'are a,ain, 'ith the !se of rende@%o!s &o! kno' that the
passed data is act!all& in !se )& the other thread 'hen the callin, thread contin!es
e*ec!tion, 'hereas !sin, ordinar& ethod calls for data transfer /e%en if the ethod
)elon,s to an acti%e o)6ect0 the e*ec!tin, thread !sin, the pro%ided data can )e !n -
affected /for soe tie after the call0.
9hen !sin, seaphores, one sho!ld also )e a'are of the dra')acks /)oth in ,eneral
and copared to other techni2!es introd!ced later0. 5f seaphores are inlined in the
code 'here%er !t!al e*cl!sion is to )e accoplished, it ,ets hard to read and
aintain the pro,ra. 5f it is not clear 'here the critical sections act!all& are, the
risk for shared data not )ein, locked increases. Another case is stateents like if,
thro', and ret!rn !nintentionall& res!lts in a reso!rce )ein, left in a locked state,
and the entire application ,ets locked !p or does not 'ork an&ore. A first ,ood r!le
therefore is to place critical sections as ethods in separate classes.
Another disad%ant a,e is 'hen a thread teporaril& has to lea%e a critical section,
'aitin, for soe condition to )e f!lfilled, it can in soe cases )e rather coplicated
to ipleent. (he seaphore concept is as s!ch s!fficient for ipleent ation of an&
!lti- threaded pro,ra, )!t the application a& )e !nnecessaril& cople* co-
pared to !sin, onitors or essa,es as e*plained )elo'. (herefore, seaphores are
)est s!ited for lo'-le%el and sall soft'are od!les 'ith special deands on effi-
The semaphores package
(o s!pport the !se of seaphores in .a%a, a packa,e se.lth.cs.real-
time.semaphore has )een de%eloped. Different classes are pro%idin, ipleent a -
tions for different t&pes of seaphores, s!ch as a class MutexSem for the !t!al e*-
cl!sion case 'here it can )e checked that ,i%e is called )& the thread c!rrentl& hold-
in, the seaphore, and a class CountingSem that for si,nalin, p!rposes is pre -
scri)ed to contain a co!nter. (he defa!lt ipleentations are 100W .a%a !sin, the
synchronized ke&'ord that is f!rther e*plained in the ne*t section. (hat is of
co!rse not accepta)le for cross-copilation to sall e)edded s&stes since1
• Uer& sall s&stes often pro%ide onl& seaphores, so synchronized has to )e
apped to seaphores and not the other 'a& aro!nd.
• Cor lo'-le%el soft'are ser%in, interr!pt s, nati%e seaphores for si,nalin, fro
the interr!pt ro!tine to threads are indispensa)le.
200E-01-11 15105 © &2
Chapter 3 Multi-Threaded Programming
(herefore, the defa!lt ipleentation is for the r!n-an&'here /that is, p!re .a%a0 case.
(he idea is then to s!pport platfors pro%idin, nati%e seaphores )& proper cross-copi-
lation tools /o!tside the scope of this chapter0.
he Semaphore interface
All seaphores pro%ide the ethods ,i%e, take, and tr&(ake. (hat is e*pressed )& the in-
terface "eaphore, 'hich is !sef!l 'hen a seaphore o)6ect is to )e !sed 'itho!t the
need to kno' 'hat t&pe of seaphore it is. (hese ethods are doc!ented as1
public void give()
5ncreents )& 1 the co!nter represented )& this seaphore, and notif& at least
one, if an&, of the 'aitin, threads. 8asicall& this eans e*ec!tin, the
follo'in, t'o lines,
++count; // Or set to true (or 1) in case of a binary semaphore.
notify(); // If any threads blocked, release the first in queue.
atomically /s&nchroni@ed, 'ith interr!pts disa)led, or in hard'are, as
accoplished in a partic!lar t&pe of s&ste0.
public void take()
Ca!ses the callin, thread to )lock !ntil the co!nter that represents this
seaphore o)tains a positi%e %al!e. :n ret!rn the co!nter, naed co!nt
)elo', is decreented )& 1. 8asicall& this eans e*ec!tin,
while (count<1) wait(); // wait suspends execution until notify.
--count; // Or set to false (or 0) if binary.
atomically /as for ,i%e0.
public boolean tryTake(long timeout)
Ca!ses the callin, thread to )lock !ntil the co!nter that represents this
seaphore o)tains a positi%e %al!e /6!st like the ordinar& take ethod0 or
!ntil the tieo!t tie has passed. 5f, d!e to other threads callin, ,i%e, the
seaphore is possi)le to take, )!t the caller of take is not resched!led for
e*ec!tion !ntil after the tieo!t tie after its call of take, it is considered as a
tieo!t and hence false is ret!rned /and the internal state of the seaphore is
left !nchan,ed0.
Note that the seaphore operations are not ordinar& ethods; the& ha%e to !tili@e
soe t&pe of s&ste call to s!spend and res!e e*ec!tion. (hat is, 'hen take re-
s!lts in s!spended e*ec!tion as entioned in the coent a)o%e, the thread is no
lon,er read& for e*ec!tion and the sched!ler of the operatin, s&ste /or .U7 if so
called ,reen threads are !sed0 p!ts the thread /in ters of data incl!din, the con-
te*t0 in the 'aitin, 2!e!e of the seaphore. <ence, the thread cons!es no CP$
tie 'hile )ein, )locked. (he entioned s&ste call can )e a nati%e seaphore op-
eration /'hen seaphores are s!pported )& the :"0. 9hen !sin, a .U7, the s&ste
call is accoplished )& the !se of s&nchroni@ed /e*plained )elo'0.
Semaphore classes
(he classes ipleentin, the "eaphore interface, and their oti%ation, are as fol-
)6 >eal- (ie Pro,rain, H a .a%a- )ased approach
Resources and mutual exclusion – Semaphores
A "eaphore containin, a )oolean fla, instead of a co!nter, to s!pport
si,nalin, in cases 'hen 'aitin, threads sho!ld not catch !p 'ith s!ccessi%e
issed calls of ,i%e. 5n the defa!lt .a%a ipleent ation a )oolean is !sed to
keep the state of the seaphore. Nati%e appin,s can !se that, or a )it, or a
co!nter 'ith a a*i! %al!e of one as in 'in+2.
8asic t&pe of seaphore containin, a co!nter 'hich is increented )& one for
each call to ,i%e, and decreented )& one for each ret!rnin, call of take. A
t&pical si,nalin, e*aple !sin, this t&pe of seaphore 'as sho'n in Ci,!re +-
Co!ntin, seaphore perittin, increents and decreents that are ,reater
than one. $sef!l 'hen t'o /or ore0 s!ccessi%e calls of take needs to )e done
'itho!t risk for preeption in )et'een.
A "eaphore 'ith special s!pport for mut !al ex cl!sion. Cirst, the
ipleent ation a& check that the thread callin, ,i%e o'ns the lock /that is,
has taken the 7!te*"e0. "econdl&, this t&pe of seaphore is re2!ired to
pro%ide so called priorit& inheritance /see Chapter 40 as a ean to o)tain
)o!nded response ties for hi,h priorit& threads 'hen a lo'-priorit& thread is
preepted and then star%ed 'hen in a critical section.
5n principle, not considerin, real- tie re2!ireents and ass!in, correct pro,ra -
in,, the MultistepSem co!ld )e !sed in all cases /or the CountingSem in alost all
cases0, )!t pro%idin, and !sin, s!ita)le a)stractions is %al!a)le in soft'are de%elop-
ent. Proposed !sa,e1
• Declare seaphore attri)!tes and ar,!ents to )e of t&pe Semaphore, e*cept
'hen the code is tailored to a specific t&pe of seaphore.
• 5n noral cases, instantiate a MutexSem for !t!al e*cl!sion and a CountingSem
for si,nalin,.
• 5n special cases, !se the BinarySem for si,nalin, 'hen =catchin, !p= is not desired
or for siplified reso!rce reser%ation, and !se the MultistepSem for si,nalin,
!ltiple steps in an atoic anner or for atoic reser%ation of !ltiple re-
All "eaphore classes are declared final to perit optial code and appin, to na -
ti%e seaphores 'hen cross- copilin, to sall e)edded s&stes.
Errors and exceptions
9hen a )lockin, seaphore operation is interr!pted, it res!lts in SemInterrupted
)ein, thro'n. 9hen a thread calls mutex.give /'here mutex is an instance of Mu-
texSem0 'itho!t first ha%in, ac2!ired it )& callin, take, a SemViolation is thro'n.
(he caller is not e*pected to catch these, e*cept for properl& sh!t- do'n of the appli -
cation, since contin!ed e*ec!tion ost likel& 'ill %iolate reso!rce allocation r!les
200E-01-11 15105 © )1
Chapter 3 Multi-Threaded Programming
and res!lt in conc!rrenc& fa!lts. (herefore, SemInterrupted and SemViolation are
s!)classes of java.lang.Error. (hat also ,i%es the )enefit that calls do not ha%e to
)e s!rro!nded )& tr&- catch. 9hen there are reasons to catch the, for instance ri,ht
)efore thread terination, that is of co!rse possi)le.
)' >eal- (ie Pro,rain, H a .a%a- )ased approach
Objects providing mutual exclusion – Monitors
3.3 Objects providing mutual exclusion – Monitors
(he ke& idea 'ith the concept of onitors is to co)ine o)6ect oriented pro,ra -
in, 'ith !t!al e*cl!sion. As descri)ed in Chapter 2, an o)6ect 'ith ethods that
are !t!all& e*cl!si%e is called a onitor. Act!all&, the onitor concept as initiall&
defined )& <oare in 1IF4 'as onl& )ased on a)stract data t&pes, )!t classes as in
.a%a accoplishes that and ore. 7onitors do in principle, ho'e%er, re2!ire the
!t!al e*cl!sion to )e iplicit. (hat 'o!ld ean, in .a%a, that the class definin,
the onitor sho!ld )e ta,,ed to coprise a onitor /for instance )& !sin, a ke&'ord
onitor precedin, the class0, 'hich sho!ld ipl& !t!al e*cl!sion )et'een all
ethods and all fields )ein, protected. Cor perforance reasons, that is not the 'a&
onitors are s!pported in .a%a. 5nstead, the follo'in, applies.
9hen threads conc!rrentl& call ethods of an o)6ect, the calls are as&nchrono!s
since the& can occ!r independentl& 'itho!t an& s&nchroni@ation. 9hen, on the other
hand, calls are to )e !tall& e*cl!si%e /as for the )ank acco!nt0 'e !st restrict
conc!rrent calls so that the& are not as&nchrono!s 'ith respect to each other. 5n
other 'ords, ethods need to )e called s&nchrono!s, 'hich in .a%a is accoplished
)& declarin, the as synchronized.
Synchronized methods
All ethods that sho!ld )e !t!all& e*cl!si%e has to )e declared synchronized.
7ethods that are not s&nchroni@ed, as 'ell as the data fields /or attri)!tes0, onl&
o)e&s the !s!al protection r!les and are fro a conc!rrenc& point of %ie' dependin,
on pro,rai n, discipline. 5t co!ld )e considered as a desi,n fla' of the .a%a lan -
,!a,e that a class as such cannot be declared synchroni6ed . "!ch a sol!tion co!ld
ha%e ent that all ethods are iplicitl& s&nchroni@ed and onl& s&nchroni@ed eth -
ods can access the attri)!tes. 8!t, as entioned, this is not the case in .a%a; &o!
ha%e to )e a'are a)o!t ho' conc!rrent access can )e ade and ipleent classes
so that the& are thread safe /reentrant ethods and !t!al e*cl!sion 'here%er !l -
tiple threads can call0 if that is re2!ired.
A desi,n decision not to ake an o)6ectDpacka,eDli)rar&Dapplication thread safe
sho!ld )e 'ell doc!ented. :ne s!ch e*aple is the so called "'in, ,raphic pack -
a,es /javax.swing.*0 'hich is )asicall& not thread safe; ha%in, all those ethods
s&nchroni@ed 'o!ld )e a 'aste of B$5 perforance since alost all calls are ade
se2!entiall& )& a sin,le thread an&'a&, 'hich is accoplished )& con%ertin, the
conc!rrentl& occ!rrin, !ser actions into EventObject1s that are )!ffered and pro-
cessed one at a tie. E%ent processin, is the topic of the ne*t section, here 'e con-
sider the case 'hen conc!rrentl& e*ec!tin, threads act!all& need to call ethods of
the sae o)6ect.
"iilar to 'hen 'e !se a MutexSem as a lock to pro%ide e*cl!si%e access to an o)6ect,
'e need soe kind of lock also 'hen ethods are s&nchroni@ed. 5n .a%a, there is
200E-01-11 15105 © )3
Chapter 3 Multi-Threaded Programming
s!ch a lock a%aila)le in each o)6ect, e%en for the ordinar& onesX (he s&nchroni@ed
ke&'ord tells the copiler to ,enerate code that !ses the lock. (here)&, the pro,ra
,ets ore eas& to read and 'rite. Cor instance, consider the )ank acco!nt in Ci,!re
Synchronized blocks
9hile the !se of s&nchroni@ed ethods ipro%es reada)ilit& /copared to the !se of
seaphores0, .a%a also pro%ides a less /copared to proper !se of onitors0 str!c -
t!red alternati%e for lockin, an o)6ect; the synchroni6ed block. 9ithin the )races the
o)6ect obj is locked for e*cl!si%e !se1
synchronized(obj) { /* Exclusive access to obj here.. */ }
:f co!rse, a s&nchroni@ed )lock !ses the sae o)6ect lock as the s&nchroni@ed eth -
ods of that o)6ect, there)& akin, the )lock and the ethods !t!all& e*cl!si%e. A
s&nchroni@ed ethod is e2!i%alent to a ethod 'ith the o!terost )lock
{ synchronized(this) { /* Method body here. */ } }
The benefit of language support
8oth s&nchroni@ed ethods and )locks are %er& con%enient 'hen ret!rnin, fro a
ethod. Copare this 'ith the !se of seaphores 'hich rese)les the sit!ation
'hen the lan,!a,eDcopiler does not s!pport s&nchroni@ation or conc!rrenc&, like in
CDCJJ. >et!rnin, a %al!e fro a onitor ethod often re2!ires the ret!rn %al!e to
)e declared as an additional local %aria)le, called ans in the follo'in, ipleent a -
tion of the class Account, not perittin, the acco!nt to )e o%erdra'n1
)& >eal- (ie Pro,rain, H a .a%a- )ased approach
Figure 3-6 The bank account class to the left uses a semaphore for locking the ob9ect to
accomplish mutual e*clusion. ;y declaring the methods synchroni6ed" as to
the right" the same thing is achieved but in a simpler and more readable
manner. )n Java" there is an invisible lock in every ob9ect.
class Account {
int balance;
Semaphore mutex = new MutexSem();
void deposit(int amount)
balance += amount;
void withdraw(int amount)
balance -= amount;
class Account {
int balance;
synchronized void deposit(int amount)
balance += amount;
synchronized void withdraw(int amount)
balance -= amount;
Objects providing mutual exclusion – Monitors
1: class Account {
2: int balance;
3: Semaphore mutex = new MutexSem();
5: void deposit(int amount) { // As in implemented above.... }
7: int withdraw(int amount) {
8: int ans = 0;
9: mutex.take();
10: if (amount > balance) {
11: ans = amount - balance;
12: balance = 0;
13: } else {
14: balance -= amount;
15: }
16: mutex.give();
17: return ans;
18: }
19: }
8ased on this code, consider the follo'in,1
• <a%in, the local %aria)le ans initiali@ed and ret!rned no lon,er akes the
seaphore operations that clear as a scope for the critical section.
• #ine G and I co!ld )e s'apped, technicall&, )!t 'hat 'o!ld happen if 'e s'ap
lines 1E and 1FM
• 5f the introd!ced if-stateent 'o!ld )e inserted in a lar,er ethod, there is the
risk that lines 10 to 15 'o!ld ha%e )een ipleented as
int withdraw(int amount) {
if (amount > balance) {
balance = 0;
return amount - balance; // Bug one.
} else {
balance -= amount;
return 0; // Bug two.
and the reso!rce 'o!ld ha%e )een locked fore%er after the first call. (hat 'o!ld
)e an eas& to find )!,, )!t 'hat if the ret!rn fro inside the ethod /)et'een
take and give0 onl& occ!rs in a %er& special case as e%al!ated in a ore cople*
if stateentM Deadlock in the shipped prod!ct after a fe' 'eeks at the c!stoer
• 5f the ans %aria)le 'o!ld )e declared as an o)6ect attri)!te, like the balance at -
tri)!te, 'e ha%e a conc!rrenc& error. 7!t!al e*cl!sion )et'een deposit and
200E-01-11 15105 © ))
Chapter 3 Multi-Threaded Programming
withdraw still 'orks /since ans is !sed onl& )& the 'ithdra' ethod0 )!t conc!r -
rent calls of 'ithdra' can ,i%e the 'ron, res!lt. (his is )eca!se the 'ithdra'
ethod no lon,er is reentrant. Cor instance, one caller /'ith lo' priorit&0 locks
the reso!rce and carries o!t the transaction, 'hile a second thread /'ith hi,h pri -
orit&0 preepts the first thread )et'een lines 1E and 1F. 9hen res!in,, the
first thread 'ill ret!rn the res!lt of the second call and the res!lt of the first
transaction is lost, that is, if amount>balance.
7akin, a ethod or f!nction reentrant )& onl& !sin, local %aria)les /allocated on
the stack of each thread0 is standard; 'e need to !nderstand that no atter if 'e
!se a lan,!a,e s!pportin, s&nchroni@ed or not. <o'e%er, 'ith the a%aila)ilit& of
s&nchroni@ed as in .a%a, 'e do not need to introd!ce the ans %aria)le at all. C!r -
therore, ret!rnin, fro a ethod ne%er res!lts in the reso!rce )ein, left in its
locked state; on ret!rn the .a%a copiler prod!ces the e*ec!ta)le code that !nlocks
the o)6ect.
Basic use of keyword synchronized
(here are cases 'hen s&nchroni@ed )locks are appropriate, )!t in ,eneral 'e )etter
follo' a fe' siple r!les1
A. Cor each class, decide if an instance sho!ld )e an ordinar& o)6ect /not carin,
a)o!t conc!rrenc&0, a thread o)6ect, or a onitor. <o not mi* threads and monit +
8. :onitors should have all public methods synchroni6ed /e*cept the constr!ctors0
and no p!)lic attri)!tes. "!)classes of onitors sho!ld also ha%e to declare all
ethods s&nchroni@ed since synchronized is not inherited.
C. 5f &o! need to make an ordinary class thread safe, &o! co!ld create a onitor )&
definin, a s!)class, )!t then &o! ha%e to o%erride all ethods in order to declare
the as s&nchroni@ed. 7ethods that are final is a pro)le. 5nstead of s!)-
classin,, it is !s!all& )etter to write a wrapper class being a monitor containing
the ordinary ob9ect.
D. <o not use synchroni6ed blocks , 'hich are contradictor& to proper o)6ect-oriented
desi,n of conc!rrent soft'are and to the onitor concept as s!ch.
(he reason for r!le A is that the actions of a thread is defined %ia a ethod /run0
'hich fro a p!rel& o)6ect-oriented point of %ie' is a ethod like an& other, 'ith
access to all attri)!tes of the o)6ect. 7!t!al e*cl!sion )et'een the internal thread
/e*ec!tin, the run ethod0 and the e*ternal threads /callin, the onitor ethods0
'o!ld re2!ire the r!n ethod to )e s&nchroni@ed as 'ell. Another alternati%e co!ld
)e to onl& access the attri)!tes of the o)6ect %ia s&nchroni@ed ethods. <o'e%er, the
conc!rrenc& correctness 'o!ld then hea%il& depend on pro,rain, discipline;
neither the copiler nor the r!n- tie s&ste can coplain a)o!t the r!n ethod
accessin, the attri)!tes /r!n is nothin, special fro a lan,!a,e point of %ie'0. (he
public, protected, and private, ke&'ords ha%e to do 'ith %isi)ilit& )et'een ordin -
ar& o)6ects; the& ha%e nothin, to do 'ith conc!rrenc&. 5n case of i*in, threads and
)* >eal- (ie Pro,rain, H a .a%a- )ased approach
Objects providing mutual exclusion – Monitors
onitors 'e ,et no help fro the copiler as 'hen 'e !se s&nchroni@ed ethods to
access protected att ri)!tes. (he lack of s!pport for the (ask a)straction co!ld )e
considered as a deficienc& of .a%a, )!t as 'ill )e ar,!ed later, the task is not a s!it -
a)le a)straction for the desi,n of o)6ect oriented conc!rrent /or real- tie0 s&stes
Use and misuse of keyword volatile
(o f!rther descrie)e the special need for conc!rrent soft'are to )e 'ell-str!ct!red
the follo'in, code snippet contains a s&nchroni@ed ethod in a thread o)6ect. 8&
)reakin, r!le A a)o%e 'e a& sa& that 'e ha%e one error, and there is a risk that
!t!al e*cl!sion 'ill not 'ork, )!t 'hat other pro)les can res!ltM
* Find five faults, concerning concurrency, in this class.
import I.robot.dest; // Import static robot destination class Dest.
public class PathCoord extends Thread {
private double x,y;
public synchronized int dist() {return Math.sqrt(x*x+y*y);}
public void int run() {
double path = 0.0; // Path coordinate, locally on thread stack.
while(!isInterrupted()) {
path = Dest.step(path); // Local data and reentrant method.
x = Dest.fx(path); // Calling one thread-safe method,
y = Dest.fy(path); // and calling another one.
Dest.nextStep(x,y); // Use x,y and wait for next sample.
<ere it can happen that a le,al %al!e x is not consistent 'ith a le,al %al!e y /to-
,ether definin, an ille,al coordinate o!tside the path for the destination of the ro)ot
otion0. (his pro)le is d!e to preeption /)et'een or in the calls of fx and fy0, in-
dependentl& of the t&pes of x and y, and despite that fx and fy each are thread
safe. <ence, this is a conc!rrenc& fa!lt and the o!tcoe of r!nnin, the soft'are is
dependent on the tiin, of the specific platforD.U7. 5n co)ination 'ith )reakin,
the r!le not to i* threads and onitors, 'e a& sa& this constit!tes t'o errors in
this class. <o'e%er, there are also t'o other conc!rrenc& pro)les that are coon
in e)edded soft'are since ost pro,raers also in ind!str& are not a'are of
1. (here is the risk that x or y ,ets corr!pted 'hen the pro,ra is not r!n on a E4-
)it achine /'here a double is stored in a sin,le achine 'ord0, 'hich is the
noral case for e)edded soft'are. (he reed& is to !se volatile like1
private double volatile x, y;
200E-01-11 15105 © ),
Chapter 3 Multi-Threaded Programming
as 'ill )e f!rther entioned 'ithin the s&nchroni@ation details )elo'.
2. E%en if 'e 'o!ld !se sin,le precision /float0 for x and y, there)& a%oidin, the
pro)le of ite 1 'itho!t !sin, volatile /that decreases perforance0, and e%en
if 'e ne%er ,et a conte*t s'itch at the critical point /e.,., d!e to the priorities and
sched!lerD:" !sed0 )et'een the calls of fx and fy, the res!lt of another thread
callin, dist co!ld still )e 'ron, or o!tdatedX (he reason is that CP$s toda&
ake e*tensi%e !se of so called data cashes coprised )& on-chip eor& that is
!ch faster to !se than the noral e*ternal /priar&0 eor&. <i,h a%ara,e
perforance is achie%ed )& storin, data locall& in the cash eor& 'itho!t 'rit -
in, to the slo'er priar& eor&. Pro)les arise 'hen data shared )& !ltiple
threads is not volatile or is not protected 'ith proper !t!al e*cl!sion /s!ch as
synchronized that res!lts in the r!ntie s&ste )ein, infored and the contant
of the cash is 'ritten to eor&0. A %aria)le !pdated )& one thread a& reain
in a cash- eor& cell 'hile another thread reads fro the priar& eor& ac-
cordin, to the address of the %aria)le, and conse2!entl& the old %al!e is o)tained
instead of the one !pdated )& the other thread.
E%en if there is reall& onl& one error in the PathCoord class a)o%e /the i*-in of the
onitor in the thread0, 'e ha%e no' listed fo!r different fa!lts that can )e the res -
!lt. "o, 'hat is the fifth possi)le fa!lt thenM (his is an !n!s!al case and it does not
appl& 'hen 'e !se a standard .U7, )!t consider the case that 'e are1 10 !sin,
%olatile for !lti- threaded consistenc&, 20 this is 'ritten in or translated to C /also
ha%in, the %olatile ke&'ord )!t 'ith a less strict definition0 and thereafter copiled
to a specific platfor /:" and CP$0 norall& s!pportin, the .a%a eanin, of %olat -
ile, and finall& +0 'e r!n the pro,ra on that platfor )!t on a achine 'ith !lti -
ple CP$s. :ne co!ld then e*pect the !ltiprocessor s!pport of that :" to handle
the eor& s!ch that the eanin, of %olatile reains, also for the case that the :"
sched!les the t'o threads to r!n on different processors. <o'e%er, this is not al -
'a&s the case /soe %ersions of !lti- processor "!n "PA>C )ein, one e*aple0,
and 'e ha%e the fifth fa!lt /'hen !sin, volatile )!t not a proper .a%a platfor0.
Note that these pro)les all disappear if access o)6ect attri)!tes )& ethods that
are synchronized, and also note that the first fo!r pro)les ill!strated in the class
PathCoord are the same if we use monitors or semaphores for !t!al e*cl!sion, and
the pro)les are the same in Java as in 0-0==. (h!s, independentl& of 'hich of
these lan,!a,es &o! !se, ipleent onitors and !t!al e*cl!sion as descri)ed
and do not mix acti9e ob5ects and moni tors .
4 9hen accoplishin, !t!al e*cl!sion in .a%a %ia a proper onitor 'ith s&nchroni@ed
ethods, or 'hen a pro,ra 'ritten in C !ses seaphore f!nctions fro soe li)rar& of
the s&ste, professional pro,raers are !s!all& a'are of the preeption aspect
represented )& the descri)ed conc!rrenc& fa!lt /first error0 of the PathCoord class. As a
/positi%e0 side effect the other possi)le r!ntie errors also disappear. 5n .a%a this is d!e to
specified properties of the .U7, 'hereas in C this is d!e to specified stora,e of so called
cashed data 'hen callin, e*ternal f!nctions. Ce' pro,raers are a'are of these other
effects )!t the e*perience that 'ell str!ct!red code is ore relia)le sho!ld )e coon.
)0 >eal- (ie Pro,rain, H a .a%a- )ased approach
Objects providing mutual exclusion – Monitors
Synchronization details
As 'ith an& set of )asic r!les, there are soe cases 'hen the e*perienced pro,ra -
er for ,ood reasons, or the )e,inner for )ad reasons, a& 'ant to )reak the r!les.
8efore doin, that, )e a'are of the pre%ios section and the follo'in,1
1. As a 'a& of doin, an!al perforance optii@ation, sall ,et and set ethods
/)elon,in, to a onitor 'ith other ethods s&nchroni@ed0 are often not declared
s&nchroni@ed. <o'e%er, the 'a& it is done is /as far as the a!thor has seen0
ostl& 'ron,, res!ltin, in %er&-hard- to-find )!,s 'hen the pro,ra is r!n on
soe platfors. (herefore, keep the follo'in, in ind1
• :nl& access data that is consistent all the tie. E%en if ,ettin, an inte,er
can )e done atoicall&, that attri)!te a& ha%e an inconsistent %al!e d!e
to cop!tations in the s&nchroni@ed ethods. 5n a non- final class 'ith
non- pri%ate attri)!tes, &o! cannot kno' 'hat s!)classes 'ill do.
• :nl& access a sin,le sin,le- 'ord %al!e /)!ilt in t&pe or o)6ect reference0 )&
a non- s&nchroni@ed onitor ethod, and if not declared volatile, ake
s!re that the !pdated %al!e is o)tained /)& other s&ste calls res!ltin, in
eor& )ein, !pdated, or )& onl& perittin, a sin,le- threaded 'rite d!r -
in, start !p or siilar0. E%en if &o! fi,!re o!t that se%eral attri)!tes can
)e chan,ed d!e do the lo,ic of other ethods, the risk is too hi,h that er -
rors are introd!ced, for instance 'hen the class is e*tended or enhanced.
An accepta)le sin,le-'ord access co!ld )e an o)6ect reference that is final
/set in constr!ctor0 )!t needs to )e fre2!entl& o)tained )& other threads.
• Attri)!tes of t&pes double or long that are accessed 'itho!t s&nchroni@a -
tion sho!ld )e declared volatile. Accordin, to the .a%a lan,!a,e specifi -
cation, all t&pes e*cept long and double are atoicall& accessed. Cor o)-
6ect references it is of co!rse cr!cial that the address %al!e does not ,et
corr!pted, 'hich 'o!ld )reak the )!ilt- in safet& /the so called sand)o*
odel0 of .a%a. (he onl& data- t&pe &o! can ass!e )ein, atoicall& ac-
cessed in nati%e code on all platfors is the byte, so ipleent ation of na -
ti%e ethods /and %irt!al achines and .a%a nati%e copilers0 re2!ires
soe care, in partic!lar for CP$s 'ith 'ord len,th less than +2 )its.
• Coent &o!r ass!ptions and decisions 'hen &o! are doin, this t&pe of
/'hat &o! think is0 cle%er pro,rain,.
<ence, )e caref!l 'hen skippin, s&nchroni@ation; s!ch optii@ation is )etter
done )& copilers and class loaders.
2. 9hen de%elopin, soft'are li)raries or coponents that sho!ld stand also iprop -
er !sa,e, s!ch as a s&nchroni@ed )lock lockin, a onitor o!tside the onitor
class, &o! )etter !se a pri%ate lock o)6ect 'hich is locked )& a s&nchroni@ed )lock
in each onitor operation. A onitor then looks like1
public class RobustMonitorExample {
200E-01-11 15105 © )2
Chapter 3 Multi-Threaded Programming
private Object lock = new Object();
// More attributes are declared here ....
public void methodOne(int x) {
synchronized(lock) {
// Attributes are accessed here....
(his 'a&, other o)6ects cannot interfere 'ith the s&nchroni@ation. A,ain, the !n -
fort!nate .a%a desi,n decision to s!pport s&nchroni@ed )locks )!t not s&nchro-
ni@ed classes 'ith appropriate seantics ca!ses e*tra tro!)le 'hen de%elopin,
relia)le soft'are. "till, the sit!ation is )etter than in other a6or lan,!a,es. >e-
call this ite 'hen readin, a)o!t wait and notify )elo'. Another e*aple 'ill
)e the non- nati%e .a%a ipleentation of seaphores.
+. Do not s&nchroni@e on p!)lic attri)!tes. (hat is, if &o! /a,ainst the ,eneral
,!ideline0 s&nchroni@e on an attri)!te like the lock in the pre%io!s ite, that at -
tri)!te sho!ld )e pri%ate or final. :ther'ise, that o)6ect reference a& chan,e
fro one s&nchroni@ation point to another, there)& reo%in, the s&nchroni@ation.
#ockin, cannot )e ens!red if the look can replaced )& an&one.
4. Do not reo%e s&nchroni@ation )& s!)classin, /!nless it is a final class and &o!
reall& kno' 'hat &o! are doin,0. 5f a )ase class declares a ethod as s&nchro -
ni@ed, the s!)class sho!ld do so too. (here is nothin, in .a%a enforcin, s!ch a
practice, and &o! i,ht 'ant to optii@e ethods in a s!)class )& oittin, s&n-
chroni@ed, )!t the risk for hard- to-find conc!rrenc& errors norall& is too hi,h
considerin, the interpla& )et'een onitor ethods.
5. 5f s&nchroni@ation is needed )et'een !ltiple onitors, s!ch as interconnected
)!ffers, the& of co!rse need an o)6ect in coon to s&nchroni@e on. An alterna -
ti%e 'o!ld )e to er,e the different onitors to for one onitor 'ith all the
f!nctionalit& incl!ded, )!t s!ita)le onitor classes a& )e a%aila)le alread&; 6!st
the si,nalin, and !t!al e*cl!sion )et'een the need to )e added. $sin, s&n-
chroni@ed )locks to s&nchroni@e on soe shared lock o)6ect /s!ch as one of the
onitors if that code has )een prepared for it0 is clearl& prefera)le copared to
re'ritin, the application.
As entioned in the last ite, the need for s&nchroni@ation )et'een o)6ects can )e
d!e to the need for si,nalin, /'hich 'e earlier accoplished )& seaphores0. 9hen
an o)6ect has )een locked )& synchronized /for a ethod or a )locks0, there can )e
conditions that need to )e f!lfilled )efore the operations on the shared data can )e
f!lfilled. .a%a pro%ides the follo'in, s!pport for that sit!ation.
*6 >eal- (ie Pro,rain, H a .a%a- )ased approach
Objects providing mutual exclusion – Monitors
Conditions – wait and notify
Consider a )!ffer 'ith operations put and get. (o accoplish !t!al e*cl!sion d!r -
in, anip!lation of the )!ffer, those ethods are t&picall& declared s&nchroni@ed.
<o'e%er, )oth in this case as 'ell as in an& other t&pes of onitors, certain condi -
tions a& need to )e f!lfilled )efore an operation can )e copleted. Cor instance,
there !st )e soethin, in the )!ffer to fetch )efore get can )e perfored, and the
)!ffer a& not )e f!ll in order to let put )e carried o!t. 5f s!ch conditions can )e
e%al!ated )efore an& shared data is anip!lated 'e co!ld sipl& cancel the opera -
tion and ake a ne' call 'hen the stat!s has chan,ed, )!t 'e also re2!ire1
• 9hen 'aitin, for a certain condition to )e f!lfilled, that thread sho!ld )e )locked
to pre%ent 'aste of CP$ tie /pollin, or )!s& 'ait, possi)l& leadin, to star%ation
of other threads, is not allo'ed0.
• 9hen the condition is f!lfilled 'e need a 'a& of 'akin, !p the )locked thread/s0.
• 9hen a thread contin!es e*ec!tion after )ein, )locked on soe condition, it has
to copete for the reso!rce a,ain since 'e ha%e to ens!re that onl& one thread at
a tie is e*ec!tin, inside the onitor /i.e., inside the critical re,ion0.
(o accoplish these feat!res, each .a%a o)6ect is e2!ipped 'ith a waitDnotify
echanis in ters of the ethods wait, notify, and notifyAll accordin, to /see
Ci,!re +-F01
(he thread e*ec!tin, 'ithin the onitor /inside a synchronized ethod or
)lock0 ,i%es !p the e*cl!si%e access, steppin, o!t to the =)ack &ard= containin,
the condition 2!e!e. (he r!ntie s&ste puts the blocked thread in the
200E-01-11 15105 © *1
Figure 3-7 The monitor concept" including the wait+ notify mechanism as a back yard.
The crosses are revolving doors" that is" the door turns in the direction of
the bent arrow and threads can only pass in the direction shown by the
straight arrow.
E*clusive area
:onitor 3ueue
0ondition 3ueue
(hr ead a)o!t
t o ent er
'ait in, for e*cl!si%e access
(hr ead 6!st left onit or
a'ait in, f!lfilled condit ion
(hr ead 'it h e*cl!si%e
access t o onit or dat a
S cheduling
Chapter 3 Multi-Threaded Programming
condition 3ueue, 'here it t&picall& is inserted in priorit& order 'ith the thread
'ith the hi,hest priorit& first. (he sa%ed conte*t of the )locked thread,
referrin, to the stack of the thread and there)& to the state of e*ec!tion, of
co!rse contains the state of the half ade onitor operation.
(hreads 'aitin, in the condition 2!e!e 'ill reain there !ntil notified )&
soe other thread, or !ntil a tieo!t occ!rs as e*plained later. (hreads that
inside the onitor chan,e an& data that affects conditions that the threads in
the condition 2!e!e i,ht 'aitin, for, sho!ld call notify to wake up one of the
blocked threads . 5f the condition 2!e!e is ept&, notif& does nothin,. 5t
depends on the r!ntie s&ste 'hich of the )locked threads that are selected
for notification, )!t here 'e ass!e the noral case that it is the first in
2!e!e thread, 'hich in t!rn is the one 'ith the hi,hest priorit&.
After the thread is notified and read& for e*ec!tion, it has to copete for CP$
tie 'ith all other threads to ad%ance its e*ec!tion point at all. 9hen
e*ec!tion ad%ances, the thread also has to copete /a,ainX0 'ith other threads
for e*cl!si%e access to the onitor, and if not s!ccessf!l it is )locked and
placed in the onitor 2!e!e /in priorit& order 'e ass!e, e%en if not specified
)& .a%a0.
4ll the threads in the condition 3ueue are notified , and there)& ade read& for
e*ec!tion. (he& are then all s!)6ect to sched!lin, as e*plained for notify.
"ince sched!lin, is not part of the .a%a specification, and since kno'in, 'hat
threads that i,ht )e !sin, the onitor re2!ires ,lo)al inforation, the
relia)le and porta)le 'a& of notification is to al'a&s call notifyAll instead of
notify; the !se of notify is p!rel& for optii@ation and perforance t!nin,
/to pre%ent e*cessi%e conte*t s'itches that can )e the case 'hen an& threads
first are !n)locked and then all )!t one calls wait a,ain 'hen the condition
a,ain is not f!lfilled0.
Note that e%en if the copiler lets &o! call these ethods an&'here in the pro,ra
/since the& are p!)lic ethods of class Object0, the& onl& 'ork if the callin, thread
first has locked the o)6ect %ia synchronized. :ther'ise, an IllegalMonitor-
StateException is thro'n.
8e a'are of the )i, difference )et'een callin, wait /i.e., Object.wait0 and callin,
sleep /i.e., Thread.sleep0 fro inside a onitor, that is, fro inside a s&nchroni@ed
ethod or )lock. Callin, wait res!lts in other threads )ein, peritted to enter the
onitor, like teporar& !nlockin, to let soe other thread chan,e the state of the
onitor as desired. Callin, sleep eans that the onitor is locked d!rin, the sleep
tie, and no other threads are allo'ed to enter d!rin, that tie.
Basic use of wait and notify
A notified thread is o%ed fro the condition 2!e!e to the onitor 2!e!e 'here it
has to copete 'ith other threads, as decided )& the !nderla&in, r!ntie s&ste
/here 'e ass!e priorit& ordered 2!e!es0. 9hen the thread holdin, the lockDonitor
*' >eal- (ie Pro,rain, H a .a%a- )ased approach
Objects providing mutual exclusion – Monitors
lea%es, the first thread in the onitor 2!e!e is !n)locked /p!t in the read& 2!e!e0
and is s!)6ect to CP$ tie sched!lin,. 5plications1
• No atter ho' lo' priorit& or 'hat :", a thread that ,ot into the onitor 'ill
coplete its onitor operation /critical section0 if ,i%en CP$ tie and if not call -
in, 'ait. 9e sa& there is no resource preemption .
• D!e to preeption /that is, e*ec!tion preeption, not to )e conf!sed 'ith the re-
so!rce preeption0, the thread holdin, the onitor 'ill reain there if hi,her
priorit& threads are sched!led for e*ec!tion instead.
• (here is nothin, sa&in, that a thread that has )een notified, 'hich eans it has
)een in the e*cl!si%e are alread&, is ,i%en access a,ain )efore an& of the ne'l& ar -
ri%ed threads in the onitor 2!e!e. (his depends on the sched!ler, ho'e%er, and
is not specified )& .a%a.
(he a6or point no' is that when a thread is continuing after wait" the condition
that was waited for still cannot be assumed to actually be fulfilled . As an e*aple,
ass!e one thread callin, obj = buffer.fetch() to ,et the ne*t o)6ect fro a
)!ffer, and that the )!ffer t!rned o!t to )e ept&. A cons!er thread callin, fetch
sho!ld of co!rse )e )locked !ntil soe other /prod!cer0 thread p!ts another o)6ect
in the )!ffer )& callin, Correspondin,l&, a prod!cer thread call -
in, post is to )e )locked !ntil the )!ffer is not f!ll. Ass!in, the siplest case 'ith
onl& one prod!cer and one cons!er, an strai,htfor'ard )!t fra,ile ipleent ation
5 5n the ori,inal %ersion of the onitor concept, proposed )& <oare in 1IF4, the notified
thread did act!all& preept the thread o'nin, the onitor. (herefore, notif& 'as onl& to
)e called as the last thin, 'ithin the onitor operation. No s!ch s&ste is kno'n to e*ist
200E-01-11 15105 © *3
2igure >+? 0lasses" with attributes and initiali6ation left out for brevity" implementing
producer+consumer communication via a bounded buffer based on ja-
va.util.ArrayList. The if (...) wait(); makes the buffer fragile@ ad+
ditional calls of notify .e.g." in other methods/ or additional threads
could course the buffering to fail.
class Producer extends Thread
public void run()
prod = source.get();;
class Consumer extends Thread
public void run()
cons = buffer.fetch();
class Buffer
synchronized void post(Object obj)
if (buff.size()==maxSize) wait();
if (buff.isEmpty()) notify();
synchronized Object fetch()
if (buff.isEmpty()) wait();
if (buff.size()==maxSize) notify();
// This Buffer is badly implemented!
Chapter 3 Multi-Threaded Programming
co!ld )e accordin, to Ci,!re +-G. 5n a ore ,eneral settin,, 'ith ore threads in-
%ol%ed or the )!ffer f!nctionalit& )ein, e*tended, the follo'in, pro)les arise /see
Ci,!re +-F01
1. E%en if the notif&in, thread calls notif& onl& 'hen the condition to proceed is :K
for the 'aitin, thread, the condition may again not be true when the waiting
thread is continuing X Ass!e 'e ha%e one prod!cer P and t'o cons!ers C1 and
C2, !sin, the Buffer like1
• C1 tries to fetch an o)6ect, )!t ,ets )locked on since the )!ffer is ept&.
• P posts an o)6ect to the )!ffer, and since the )!ffer 'as ept& that res!lts in a
notification of C1 that is o%ed fro the condition 2!e!e to the onitor 2!e!e.
• 8efore C1 is sched!led for e*ec!tion, that is, )efore C1 act!all& enters the e*-
cl!si%e area, C2 /ha%in, a hi,her priorit&0 contin!es /for e*aple after a sleep
that 'as copleted after a clock interr!pt0 and tries to enter the onitor. 5f
this happens )efore P has left the e*cl!si%e area, )oth C1 and C2 are )locked
in the onitor 2!e!e. /C1 a)o!t to contin!e after wait, )!t C2 first in the
2!e!e d!e to hi,her priorit&.0
• 9hen P lea%es the onitor, there are one o)6ect in the )!ffer. C2 enters the e*-
cl!si%e area, ,ets the o)6ect, and 'hen lea%in, C1 is o%ed to the read& 2!e!e
of the sched!ler and is allo'ed to enter the onitor /o'nin, the lock0.
• "ince C1 is contin!in, after 'ait, accordin, to the sho'n ipleent ation as -
s!in, that the )!ffer is not ept&, C1 tries to ,et the ne*t o)6ect. (here are
no s!ch o)6ect, and the )!ffer /and the application0 fails
2. 5t can )e difficult to keep track of what condition other threads are blocked on, or
it can )e hard to %erif& correctness or re%ise the code. 5n the referred )!ffer e*a-
ple it a& appear to )e siple, )!t does the )!ffer 'ork correctl& e%en for max-
Size e2!al to oneM
5f 'e 'o!ld add another ethod awaitEmpty that sho!ld )lock !ntil the )!ffer is
ept& /!sef!l d!rin, application sh!tdo'n0, or an additional ethod awaitFull
that sho!ld )lock !ntil the )!ffer is f!ll /!sef!l for special handlin, of o%erflo's0,
'hen and ho' an& ties sho!ld notify then )e calledM
5t is so eas& to o%erlook soe cases, and act!all& takin, care of all cases )& the
appropriate lo,ic /s!ch as co!nters for threads )locked on this or that condition0
leads to !nnecessar& cople* code that is hard to !nderstand and aintain.
7emedy 1 1se notifyAll instead of notify, and let other threads ree%al!ate
their conditions /ass!in, the reed& for ite 1 is !sed0. (he e*ception fro this
r!le is 'hen optii@in, for 'ell kno'n and perforance critical parts of the ap-
E Pro,rain, in .a%a, application failure t&picall& eans an ArrayOutOfBoundException
or a NullPointerException that can )e ca!,ht and handled, or at least 'e kno' 'hat and
'here it 'ent 'ron,. $sin, an !nsafe lan,!a,e s!ch as CJJ, the s&ste can crash /at a
later sta,e0 'itho!t essa,es.
*& >eal- (ie Pro,rain, H a .a%a- )ased approach
Objects providing mutual exclusion – Monitors
+. <o' do 'e ens!re concurrency correctness and predictability on an& /.a%a- co-
pati)le0 platforM As an e*aple, ass!e 'e ha%e t'o cons!er threads /C1 and
C20 and fi%e prod!cer threads /P1 to P50, and ass!e these !se o!r )!ffer accord-
in, to the follo'in,1
• (he )!ffer /Buffer in Ci,!re +-G0 is ,i%en a capacit& of fo!r /maxSize==40.
• 8oth C1 and C2 call fetch, and hence the& ,et )locked since the )!ffer is ep -
• P1 p!ts an o)6ect in the )!ffer )& callin, post, 'hich calls notify. :ne of C1
and C2, sa& C1, is o%ed to the onitor 2!e!e 'hile the other cons!er re-
ains in the condition 2!e!e.
• 8efore C1 ,ets sched!led for e*ec!tion, the other prod!cers /P2 to P50 tr& to
post an o)6ect. "ince the )!ffer 'as not ept&, C2 'as not notified. (his is ei-
ther a )!, or C1 has to notif& C2 soeho'. <o'e%er, the last prod!cer, sa& P5,
then also ,ets sched!led )efore C2 and post )locks since the )!ffer no' is f!ll.
• 9e no' ha%e t'o threads in the condition 2!e!e, one cons!er )locked on
)!ffer ept& and one prod!cer )locked on )!ffer f!ll, and one of the 'ill
ost likel& )e st!ck there for a lon, tie /possi)l& fore%er if it 'as the prod!c -
er and if that thread 'as to ser%e the ne*t application e%ent0. (his holds e%en
if 'e 'o!ld ha%e ipleented the Buffer !sin, while instead instead of if
accordin, to ite 1, )!t the remedy of item ' .or%s .
5tes 2 and + are siilar in that the& )oth oti%ate the !se of notifyAll instead of
notify. (he difference is that 'hile 'e accordin, to ite 2 act!all& a& )e a)le to
optii@e and !se notif&, f!ll& tested to )e lo,icall& correct on one .U7D:", ite +
points at the conc!rrenc& pro)le that iplies the risk of application fail!re soe -
ties on soe platfors.
Another pro)le is that at an& place 'ithin &o!r pro,ra, 'here a reference to &o!r
onitor is a%aila)le, synchronized(monitor){monitor.notifyAll();} can )e
called and interfere 'ith &o!r ethods. (he sae of co!rse applies to notify and
wait. (he reedies a)o%e help also in this case. Cor optii@ed li)raries, ho'e%er,
pri%ate notification o)6ects can )e !sed, like the pri%ate lock o)6ect descri)ed in the
a)o%e section a)o!t "&nchroni@ation details.
A radical reed& 'o!ld )e to al'a&s notif& all threads 'hene%er an&thin, has
chan,ed. Cor instance, the 8!ffer class in Ci,!re +-G co!ld )e ipleented like in
the left %ersion in Ci,!re +-I, 'here the s!,,estions fro the a)o%e ites ha%e )een
considered. Decreased perforance coes fro notifyAll /'hich is a s&ste call
that is ore e*pensi%e than checkin, ordinar& data0 )ein, called e%en if there for
s!re is no thread in the condition 2!e!e, and there are no lo,ic separatin, )et'een
the f!ll and ept& cases. A reasona)le trade- off /!sin, notifyAll to a%oid the de-
scri)ed pro)les0 is sho'n to the ri,ht in Ci,!re +-I.
200E-01-11 15105 © *)
Chapter 3 Multi-Threaded Programming
5n short, as r!les of th!) for pro,rain,1
A0 Al'a&s !se 'hile in front of 'ait1 while (!okToProceed) wait();
80 5nstead of notify()1 !se notifyAll();
C0 (!ne perforance 'hen needed, !sin, notify() or condition o)6ects e*plained
Keep Ci,!re +-F in ind 'hen &o! de%elop &o!r onitor ethods.
Timeout on waiting
(here are sit!ations 'hen 'aitin, for a condition to )e f!lfilled a& not take ore
than a certain ao!nt of tie. After that tie 'e 'ant to ,et a tieo!t. Cor this
p!rpose, there are t'o %ersions of 'ait acceptin, tieo!t ar,!ents1
wait(long timeout)
(he thread e*ec!tin, 'ithin the onitor teporaril& lea%es the onitor,
'aitin, for a notification as noral. 5f notif& is not called 'ithin timeout
illiseconds, 'e ,i%e !p 'aitin, and ret!rn to the caller an&'a&. (he timeout
is ini! %al!e; it can )e lon,er as an iplication of the act!al sched!lin,
of in%ol%ed threads and the internal tier. A timeout e2!al to @ero is
e2!i%alent to callin, 'ait 'itho!t an& timeout ar,!ent. A ne,ati%e timeout
res!lts in an IllegalArgumentException.
wait(long timeout, int nanos)
(he sae as pre%io!s 'ait )!t 'ith the tieo!t tie set to
** >eal- (ie Pro,rain, H a .a%a- )ased approach
2igure >+A Two alternative implementations of the ;uffer class. <eclarations" initiali6a +
tions" and e*ception handling is omitted as in 2igure >+'.)n the left version"
all methods always call notifyAll .does not need to be last/" possibly result +
ing in performance problems. )n the version to the right" robustness and per+
formance should be acceptable.
class Buffer // Inefficient!!
synchronized void post(Object obj)
while (buff.size()>=maxSize) {
synchronized Object fetch()
while (buff.isEmpty()) {
class Buffer // Well done.
synchronized void post(Object obj)
while (buff.size()>=maxSize) {
if (buff.isEmpty()) notifyAll();
synchronized Object fetch()
while (buff.isEmpty()) {
if (buff.size()>=maxSize) notifyAll();
Objects providing mutual exclusion – Monitors
1000000*timeout+nanos nanoseconds. A,ain, this is a ini! tie that
depends on the act!al sched!lin,, if the resol!tion of tie in o!r r!ntie
s&ste is hi,h eno!,h. <o'e%er, 'ith s resol!tion or lo'er, the nanos are
ro!nded to the nearest s /X0 'hich iplies that the ini! tieo!t tie
can )e !p to 0.5 s shorter than re2!ested, )!t not shorter than the timeout
since that %al!e is ro!nded !p'ards if the clock resol!tion is lo'er than 1 s.
Note the difference )et'een callin, java.lang.Thread.sleep(delay) fro 'ithin a
onitor, and callin, java.lang.Object.wait(delay). (he forer keeps the onitor
locked d!rin, 'aitin,Dsleepin,, 'hereas the latter lets other threads access the
onitor d!rin, the dela& tie. 5t is, ho'e%er, diffic!lt to ens!re that wait(delay)
act!all& dela&s for at least delay s since notify in other ethods /for e*aple in
!nkno'n s!)classes0 can interfere. (herefore, a dela& 'ithin a onitor sho!ld )e
ipleented siilar to1
synchronized monitorSleep(long timeout) throws InterruptedException
long tf = System.currentTimeMillis()+timeout;
while ((timeout=tf-System.currentTimeMillis())>0) wait(timeout);
Also note that if tieo!t illiseconds elapsed fro the call of 'ait !ntil the callin,
thread e*ec!tes the instr!ction follo'in, 'ait, 'e cannot distin,!ish )et'een if1
1. (he wait 'as called and timeout s later 'e contin!ed after a tieo!t.
2. (he wait 'as called and )efore the timeout tie soe other thread called noti-
fy, )!t d!e to sched!lin, ore than timeout s elapsed )efore the stateent af-
ter 'ait 'as e*ec!ted.
+. :ther threads 'ere sched!led for e*ec!tion ri,ht )efore 'ait 'as act!all& called,
then d!rin, the 'ait soe other thread called notif&, )!t d!e to the initial dela&
ore than tieo!t s elapsed.
(h!s, e%en if it is onl& in case 1 that the r!ntie s&ste iss!ed a tieo!t, 'e can
o)tain 'aitin, for that ao!nt of tie d!e to the /platfor dependent0 sched!lin,.
5n code this eans, dt can )e ,reater than timeout e%en if wait 'as copleted d!e
to a notification1
long t0 = System.currentTimeMillis();
long dt = System.currentTimeMillis()-t0;
5s this a pro)leM Norall& not; it does !s!all& not atter if 'e 'ere notified or
not, it is the inferred dela& that atters for the callin, thread. <ence, if dt>time-
out it is considered as a tieo!t. :n the other hand, if the state of the onitor stat -
ed that o!r thread 'as 'aitin,, and soe other thread callin, notifyAll deter -
ined that it iss!ed the notification on tie /)efore a tieo!t occ!rred0 and s!)se -
2!entl& acted accordin, to that, the possi)le cases 2 and + a)o%e a& ipl& a need
for soe ore onitor lo,ic. (hat is, if it lo,icall& is not a tieo!t, onl& checkin, if
200E-01-11 15105 © *,
Chapter 3 Multi-Threaded Programming
dt>timeout after the pre%io!s code fra,ent is not s!fficient; conc!rrenc& correct -
ness a& re2!ire soe ore onitor lo,ic to cope 'ith all possi)le interlea%in,s, as
Interrupted waiting
9hen a thread that is )locked on wait /'ith or 'itho!t tieo!t0, or on sleep as de-
scri)ed on pa,e +G, the )lockin, is interr!pted and an InterruptedException is
thro'n to the callin, thread. (he appropriate handlin, of s!ch an interr!pt ed 'ait
is t&picall& kno'nDdefined in the callin, thread o!tside the onitor ethods. <ence,
it !st propa,ate to the caller, so the o)%io!s choice 'o!ld )e to let e%er& potential -
l& )lockin, onitor ethods )e declared to thro' an InterruptedException. <o'-
e%er, in partic!lar 'hen there are se%eral le%els of calls, this soon ,ets %er& ess&.
C!rtherore, the onitor ethod cannot coplete its operation if the condition is
not f!lfilled, and it cannot sipl& ret!rn )efore the operation is copleted either
/)oth these alternati%es 'o!ld %iolate the correctness of the onitor0.
"o, the onl& reasona)le alternati%e is to thro' a Throwable o)6ect that 'e do not
need to catch or declare. .a%a pro%ides t'o alternati%es for doin, that1 thro'in, an
RuntimeException 'hich is an Exception, or thro'in, an Error. (o ephasis that
the noral !ser code is not s!pposed to catch an interr!pted 'ait /since it in ost
cases needs to propa,ate to the o!terost le%el of the thread0, thro'in, an Error is
the appropriate sol!tion. (hat is, 'e thro' an instance of RTInterrupted, 'hich is a
s!)class to java.lang.Error. (his sol!tion corresponds to the SemViolation as de-
scri)ed on pa,e 51 for seaphores.
(he iplication is that 'e norall& call wait accordin, to1
{ //.....
while (!ok) {
try {
} catch (InterruptedException exc) {
throw new RTInterrupted(exc);
Note that 'hen an InterruptedException is thro'n, the interr!pted- fla, of that
thread is cleared. <ence, it is onl& the fact that 'e ,et to the catch cla!se that tells
!s that the thread is interr!pted, and after the catch it is onl& the thro'n RTInter-
rupted that carries the interr!pt inforation 'hen the call stack is popped.
5f 'e !se a frae'ork that is predefined to catch InterruptedException specifical -
l&, an RTInterrupted can of co!rse )e con%erted )ack to an InterruptedException
)& catchin, the error and thro'in, a ne' InterruptedException /or ,ettin, the
ori,inal e*ception )& callin, getCause, see the e*ception- chainin, of ja-
va.lang.Throwable in .DK1.4 and later0.
*0 >eal- (ie Pro,rain, H a .a%a- )ased approach
Objects providing mutual exclusion – Monitors
"oeties interr!ptin, a thread is !sed to act!all& interr!pt a coand or action
in an alost e*pected 'a&. (hat is, instead of cl!tterin, the code 'ith a lot of tests
if the operation is to )e a)orted, 'e can let e*ec!tion contin!e !ntil it reaches a
)lockin, call and then !tili@e the thro'n RTInterrupted. Cor instance, a ro)ot per -
forin, its task accordin, to a se2!ence of instr!ctions can )e interr!pted )& the op-
erator 'ho iss!es another task or sipl& stops the ro)ot d!e to soe fa!lt. (he
thread that handles operator inp!t can then interr!pt the on,oin, ro)ot 'ork, and
since cop!ters are faster than echanics the 'ork thread 'ill )e )locked on ,et -
tin, a ne' order or on the copletion of last order. 8& catchin, InterruptedExcep-
tion and con%ertin, it to an RTInterrupted in 'hate%er onitor it occ!rs, 'e can
then catch the RTInterrupted and terinate the thread like1
class RobotDuty extends Thread
public void run()
try {
while (doWork(Master.nextInstruction())) {};
} catch (RTInterrupted) { Master.workAborted();} // Acknowledge.
} // No more work; end of duty!
(erinati n, the thread /and creatin, a ne' one for the ne*t 'ork0 like in this e*-
aple is con%enient for handlin, sessions that ha%e a finite life tie, s!ch as pro-
cessin, a )atch recipe in a cheical ind!str&, or carr&in, o!t an e-)!siness transac -
tion; the state of the session is kept )& the thread, and )oth the acti%it& and the
state ,ets ,ar)a,e- collected 'hen the session is finished. 5n feed)ack control, on the
other hand, 'e !s!all& create the threads that e*ec!te d!rin, the entire lifetieD!p -
tie of the s&ste; the state of the controlled s&ste needs to )e aintained also
o%er ode chan,es and the like, and the control can )e sensiti%e to dela&s d!rin,
creation of ne' threads.
More on monitor programming
(he follo'in, applies to the !se of standard .a%a packa,es, 'hereas enhanced s!p -
port for onitors 'ill )e introd!ced in Chapter 4.
Static monitors – locking class variables
E*ec!tin, s&nchroni@ed code res!lts in the s&nchroni@ed ob5ect )ein, locked. (hat
is, !t!al e*cl!sion is pro%ided for the o)6ect /not the class0 and conc!rrent access
to different o)6ects of the sae class is, of co!rse, still peritted. <o'e%er, there
a& )e attri)!tes that are shared )et'een all o)6ects of a certain t&pe, so called
static attri)!tes or class %aria)les. 7!t!al e*cl!sion then re2!ires special care.
E%en if the o)6ect pro%ides !t!al e*cl!sion on its attri)!tes, for instance )& ha%in,
all attri)!tes pri%ate and all non- static ethods s&nchroni@ed, the class %aria)les
are still not locked. (he reason is that the class as s!ch is another o)6ect 'hich
needs to )e locked separatel&, either )& a static synchronized ethod or )& a
200E-01-11 15105 © *2
Chapter 3 Multi-Threaded Programming
synchronized(static_attribute){} )lock. 5n the sae 'a&, since a static ethod
has no reference to =this' o)6ect, a static ethod does not pro%ide !t!al e*cl!sion
for an& non- static ethods. <ence, lockin, for classes /static attri)!tes0 and o)6ects
are different thin,s, ipl&in, that a inside a s&nchroni@ed ethod lockin, either the
class or the o)6ect, &o! ha%e to p!t a s&nchroni@ed )lock for e*plicitl& lockin, the
other, if )oth the class and o)6ect need to )e locked at the sae tie.
Monitors versus semaphores
(he onitor concept can )e accoplished in different 'a&s. 5n .a%a, onitors are
not e*actl& s!pported, )!t s&nchroni@ed ethods /and a fe' siple r!les0 let !s con-
%enientl& accoplish onitors. 5n practice, 'e a& sa& that .a%a pro%ides onitors,
as 'ell as possi)ilities to a%oid /)& oittin, s&nchroni@ed0 the o%erhead of o)6ect
lockin, 'hen 'e /for s!re0 can ded!ce that the pro,ra 'ill )e correct e%en 'itho!t
lockin,. An&ho', ha%in, s&nchroni@ed )!ilt into the pro,rain, lan,!a,e is of
,reat %al!e. 5n lan,!a,es 'itho!t s!ch s!pport, 'e ha%e to !se li)rar& f!nctions in
co)ination 'ith pro,rain, con%entions.
7onitors and seaphores ha%e e2!al e*pressi%e po'er; a pro,ra !sin, on of the
echaniss can al'a&s )e re'ritten !sin, onl& the other echanis, )!t it can )e
hard in practice.
• "ince a seaphore class is easil& ipleented )& a onitor /pro%idin, the eth -
ods take and give0 it is !s!all& strai,ht for'ard to re'rite the pro,ra !sin,
onl& onitors. <o'e%er, if an interr!pt ro!tine /a static ethod 'itho!t ar,! -
ents that is connected to a hard'are interr!pt0 is to call give /e.,. to si,nal that
data is a%aila)le in a hard'are )!ffer0, 'e cannot !se an ipleentation that is
)ased on s&nchroni@ed /since an interr!pt cannot )e )locked e%en if the s&nchro -
ni@ed o)6ect is locked0.
• 5pleentin, onitors !sin, seaphores is tro!)lesoe 'hen 'aitDnotif& is
!sed. (he pro)le is that the 'aitin, thread has to take one seaphore /to )e
!sed for si,nalin, 'hen the condition is f!lfilled0 and give one seaphore /the
!te* to let other threads access shared data0 atomically as one operation . (he
sol!tion is to let each thread ha%e its o'n si,nalin, seaphore.
Clearl&, )oth seaphores and onitors are needed, )!t in different sit!ations.
Polling locking state
"ince .DK1.4, class 6a%a.lan,.(hread contains a ethod
static boolean holdsLock(Object obj)
that ret!rns true if and onl& if the c!rrent thread holds the onitor lock on the
specified o)6ect. Do not !se this ethod, e*cept for special cases s!ch as test- cases
'here the lockin, of o)6ects need to )e %erified. 5n partic!lar, keep in ind that
e%en if holdsLock ret!rns one %al!e, the opposite co!ld )e the case one achine in-
str!ction /of that thread, and a fe' conte*t s'itches0 later. .!st like there /on p!r -
pose0 are no ethods for o)tainin, the state of a seaphore /'itho!t tr&in, to ac-
2!ire it0, to a%oid )ad sol!tions on conc!rrenc& pro)les, &o! sho!ld not desi,n &o!r
,6 >eal- (ie Pro,rain, H a .a%a- )ased approach
Objects providing mutual exclusion – Monitors
application s!ch that holdsLock is needed.
Multiple conditions
(o separate )et'een different conditions, it 'o!ld )e desira)le to ha%e !ltiple con-
ditions attached to a onitor o)6ect, instead of the sin,le iplicit condition that is
associated 'ith each .a%a o)6ect. (he reason is perforance; instead of notif&in, all
threads 'hen an&thin, has chan,ed, res!ltin, in an& conte*t s'itches e%en if
there is onl& one or a fe' threads that 'ait for that partic!lar chan,e. "ince .DK1.5
there are the packa,e java.util.concurrent.locks incl!din, interfaces Lock and
Condition, and classes ipleentin, these interfaces. <o'e%er, !sa,e iplies that
the s&nchroni@ed and the )enefits of lan,!a,e s!pport is lost. (herefore, 'e 'ill in-
trod!ce /in Chapter 40 another 'a& of accoplishin, !ltiple conditions, s!ch that
'e can still ha%e ethods s&nchroni@ed. (his also eans that the code chan,es
'hen chan,in, fro the )!ilt- in conditions to !ltiple /naed0 conditions 'ill )e
sall, opposed to the !se of .DK1.5 'here si,nificant refactorin, is re2!ired.
200E-01-11 15105 © ,1
Chapter 3 Multi-Threaded Programming
3.4 Message-based communication – Mailboxes
5nstead of the lo'-le%el characteristics of seaphores, the desire to s!pport conc!r -
renc& in an o)6ect oriented 'a& led to onitors; passi%e o)6ects !sed to ipleent
colla)oration )et'een acti%e o)6ects. 5n an& cases, ho'e%er, 'e can )enefit fro
ha%in, s!ch passi%e o)6ects 'ith additional f!nctionalit& for1
:ften threads 'ork in prod!cer- cons!er like sit!ations 'hen transit ted
o)6ects need to )e )!ffered in soe t&pe of 2!e!e. (hat lets the threads 'ork
ore as&nchrono!sl& 'ith respect to each other. (hat is, e%en if there are
soe teporar& )lockin, 'hen postin,Dfetchin, o)6ects intoDfro the 2!e!e /to
accoplish !t!al e*cl!sion d!rin, the ass!a)l& short 2!e!in, operations0,
a )!ffer o%erall lets the threads operate ore independentl& of each other.
Acti%it& interaction1
(raditionall&, )efore the eail era, essa,es 'ere sent %ia ail)o*es /passi%e
o)6ects pro%idin, )!fferin,0 and distri)!ted to the ail)o* of the addressee. 5f
the sender and recei%er are close to each other /like threads in the sae .U70,
and the sender kno's /has a reference to0 'here the recei%er is, the o%erhead
of distri)!tion /cost of the stap and ail dela&0 can )e a%oided )& p!ttin, the
essa,e directl& in the recei%ers ail)o*. An&ho', e%en if the essa,es
/transi tted o)6ects0 are )!ffered in a passi%e o)6ect /the ail)o*0, the ai is
to send it to soe other acti%e o)6ect /person0, 'hich deser%es special s!pport.
5f the sender and the recei%er of a essa,e are not close to or not a'are of each
others location, it is desira)le to ha%e soe ail distri)!tion s&ste. E%en if
the topic of distri)!ted s&stes is o!tside the scope of this chapter,
co!nicatin, %ia essa,es akes !s prepared for the sit!ation 'hen each
essa,e has to )e sent %ia ordinar& ail; the essa,e can look the sae, onl&
the ailin, differs. 5f 'e 'o!ld call the recei%in, acti%e o)6ect directl&, the
addressee 'o!ld need to )e a%aila)le at that partic!lar tie. (herefore,
co!nicatin, %ia essa,es can )e a ,ood ,eneric sol!tion.
Data protection /!sin, private or protected in .a%a0 ens!res encaps!lation of
se2!ential pro,ras, 'hich eans that o)6ects 'ill )e ens!red to f!nction
independentl& of each other. Cor real- tie pro,ras that is not eno!,h; 'hen
ethods of another o)6ect is called fro a tie- a'are thread /lookin, at the
clock fre2!entl&0, the caller 3,i%es !p it=s o'n 'ill4 and coits itself to
perforin, the instr!ctions ,i%en in the /hidden0 ipleentation of the called
ethod, 'hich can res!lt in )lockin, for a lon, tie. <ence, threads ,i%e !p
their tiel& )eha%ior !nless co!nication is perfored differentl&.
(o ipro%e on these aspects, co!nication %ia essa,es /instead of %ia ethods
and shared data0 'ill )e introd!ced in this section. :ri,inall& and traditionall&, this
'as referred to as mailbo*es .
,' >eal- (ie Pro,rain, H a .a%a- )ased approach
Message-based communication – Mailboxes
Cro one point of %ie', a so called ail)o* is nothin, )!t a special t&pe of onitor,
so 'e do not need an& additional s!pport fro the lan,!a,e /no ne' ke&'ords like
synchronized 'hich s!pports onitors0. Cro another point of %ie', 'hen the
a)o%e aspects are iportant, essa,e )ased o)6ect interaction can )e considered to
)e f!ndaent al, so let !s start 'ith soe considerations a)o!t the a)straction 'e
deal 'ith.
More on object interaction
7ethod calls in a lan,!a,eDs&ste pro%idin, onl& passi%e o)6ects are )& definition a
s&nchrono!s t&pe of co!nication. (hat is, passi%e o)6ects 'ork s&nchrono!sl&
since the& share the sae thread of e*ec!tion. 5n other 'ords, this t&pe of co!ni -
cation )et'een o)6ects is s&nchrono!s since the called o)6ect reains in its 'ell de-
fined state d!rin, the data transfer.
D!rin, a ethod call, the caller enters the scope of the ethod 'ithin the scope of
the called o)6ect, perforin, e*actl& 'hat the ethod states. 5n a sin,le-threaded
s&ste this is fine; data access %ia ethods pro%ide encaps!lation and data a)strac -
tion. 9hen all o)6ects are e*ec!ted )& the sae thread, 'e act!all& do not think of
an& thread at all. Data is transferred %ia ar,!ents and ret!rn %al!es, in )oth di-
rections )et'een the o)6ects, 'hich is strai,htfor'ard and efficient in sin,le-thread -
ed applications.
(o s!pport !lti- threaded applications, the pro,rain, lan,!a,e co!ld pro%ide
acti%e /conc!rrentl& e*ec!tin,0 o)6ects, and odels other than ethod calls for data
transfer )et'een o)6ects. 5n fact, 'ithin o)6ect-oriented pro,rain, in ,eneral,
co!nication )et'een o)6ects are /as in the lan,!a,e "alltalk0 often referred to
as essa,e passin,. 5n .a%a, o)6ect interaction stes fro the traditional /cop!ta -
tionall& efficient0 CDCJJ approach 'ith ethod calls 'hich are )asicall& the sae as
f!nction calls in C. <ence, in .a%a as 'ell as in ost other lan,!a,es, as&nchrono!s
co!nication sho!ld )e accoplished )& a class ipleentin, soe t&pe of ail -
)o* or )!ffer s!pportin, the principle of essa,e passin,.
(hinkin, a)o!t real- life actors, sendin, a essa,e is a nat!ral 'a& of transferrin,
inforation, in partic!lar 'hen the sender and the recei%er are actin, conc!rrentl&
)!t not s&nchroni@ed /that is, perforin, actions independentl& of each other0. (he
essa,e need to )e teporaril& stored /)!ffered0 soeho' after )ein, sent !ntil )e-
in, recei%ed. (oda&, inforation is ost often stored and transit ted electronicall&.
:n the 5nternet, essa,es )et'een h!ans are ainl& accoplished )& e-ail, )!t
in technical s&stes 'e also !se an& other essa,e principles dependin, on appli -
cation and de%elopent needs.
Events and buffers
Ass!in, the sendin, and recei%in, thread )elon, to the sae pro,ra, 'hich is
the case in this entire chapter, the sender and recei%er can refer to shared o)6ects.
200E-01-11 15105 © ,3
Chapter 3 Multi-Threaded Programming
(h!s, the )!ffer 'e need can )e a onitor. 9e a& copare 'ith essa,es 'ithin
!ser interaction packa,es s!ch as the A9(. "!ch essa,es are called e%ents since
the& represent an application e%ent, )!t the& are not )!ffered e*cept )efore )ein,
fed into the application. Additionall&, the A9( InputEvents are tie- staped so
the ,raphics classes and the application can react accordin,l& to 'hen the e%ent
/s!ch as a o!se click0 occ!rred ph&sicall&, 'hich can )e 2!ite different fro 'hen
the e%ent is processed /in partic!lar on a hea%il& loaded s&ste0.
Cor instance, ass!e t'o o!se clicks sho!ld )e considered a a do!)le-click if there
is less than 1 s )et'een the, and that the !ser clicks t'ice 'ith the second click
0.I s after the first. (hen if there is a 0.2 s dela& ri,ht after processin,Dre,isterin,
the first click, the second click 'ill )e processed 1.1 s after the first one. $sin, the
tie- staps it can still )e ded!ced that the !ser act!all& do!)le- clicked.
"iilar sit!ations appear in feed)ack control 'here the dela& /difference )et'een
c!rrent tie and e%ent tie0 res!lts is so called phase la,, 'hich in t!rn res!lts in
)ad dapin, or e%en insta)ilit&. "ince o!r ai is )oth conc!rrent and real+time pro-
,rain,, tie- stapin, o!r essa,es /at the tie of creation0 'ill al'a&s )e
Events as messages
(he eission of an e%ent o)6ect denotes soe e*plicit chan,e in state or e*ec!tion of
an application. "ince the .DK1.0 there is the class java.awt.Event 'hich 'as !sed
as the )ase class for all the e%ents in the old A9(1.0 containent- )ased e%ent od-
el. (hat odel 'as to a lar,e e*tent ipleented )& inheritance. 5t 'as con%enient
'hen pro,rai n, sall applets, )!t did not scale !p at all to lar,er application
'hich iplied e*tensi%e tra%ersals of the containent hierarch& for each e%ent
/s!ch as a o!se click0. (he java.awt.Event is kept onl& for )ack'ard copati)ilit&
and sho!ld not )e !sed.
"ince .DK1.1, the so called dele,ation- )ased e%ent odel is !sed, )oth in the A9(
/java.awt0 as 'ell as in "'in, /.CC; javax.swing0 and .a%a 8eans /java.beans0.
(he )ase class for e%ents in all these packa,es is the /packa,e and application area
ne!tral0 java.util.EventObject. (he dele,ation odel eans that e%ent handlers
re,ister thesel%es as listeners /s&nchrono!s s!)scri)ers0 to certain e%ents, and the
eitter of the e%ents calls soe e%ent- processin, ethod accordin, to the interface
for that partic!lar t&pe of e%ent. Cor instance, clickin, 'ith the o!se on a )!tton
in the B$5 /Braphical $ser 5nterface0 res!lts in an InputEvent into the .a%a B$5
packa,e /e.,. A9(0 'here the associated java.awt.Button o)6ect calls the ethod
actionPerformed(event) of the e%ent listeners that ipleent the ActionListener
interface and ha%e )een re,istered %ia the Button.addActionListener(listener)
Cor pro,rain, of e)edded s&stes in ,eneral 'e sho!ld of co!rse not depend
on an& ,raphics- related packa,es or classes /since e)edded processors !s!all& do
not pro%ide a B$5, and the& are s!)6ect to restrictions on a%aila)le eor&0 for the
core operation of the s&ste. /Copare 'ith #in!* 'hich is %er& sall 'itho!t the
,& >eal- (ie Pro,rain, H a .a%a- )ased approach
Message-based communication – Mailboxes
,raphics, copared to a f!ll installation 'ith 'indo' ana,ers and the like.0 9e
'ill, ho'e%er, ake !se of the dele,ation- )ased e%ent odel; &o! s!)scri)e on the
e%ents &o! 'ant to recei%e so the sender does not ha%e to perfor an& ass distri -
)!tion 'hich 'o!ld )e a 'aste of reso!rces.
5n the packa,es entioned a)o%e, eittin, an e%ent is !s!all& referred to as firin,
it. (o fire an e%ent 'ill )e referred to as synchronously calling the event listeners ,
'hereas to post an e%ent 'ill )e referred to as a synchronously buffer the event for
later processing )& the recei%in, thread. (his a,rees, altho!,h not stated e*plicitl&,
'ith con%entions !sed in %ario!s ,raphics packa,es, e%en if postin, is norall& han -
dled internall& and the !ser code is ass!ed to process each fired e%ent in a sin,le-
threaded anner /to ipro%e perforance and to red!ce cople*it&Dconc!rrenc&0.
(hat re2!ires that all listeners can process their e%ents instantl&, other'ise the en-
tire B$5 'o!ld =free@e= d!rin, that period of processin, or 'aitin,. Cor the sit!ation
'hen 'aitin, act!all& ha%e to )e done, for instance 'aitin, for a do'nload of a file
to )e copleted after a do'nload )!tton has )een p!shed, conc!rrent B$5- )ased
processin, can )e re2!ested and ana,ed %ia the javax.swing.SwingUtilities
and javax.swing.Timer classes. 5n SwingUtilities, &o! ha%e to !se the ethods
invokeLater and invokeAndWait, 'hich take a Runnable ar,!ent. (hat Runnable
is r!n conc!rrentl& 'ith the )!ilt- in B$5 e%ent- dispatchin, thread, )!t in s!ch a
'a& that it does not interfere 'ith the s'in,DA9( and the !ser=s e%ent processin,
code, 'hich concernin, the B$5 ainl& sta&s sin,le- threaded.
5n !lti- threaded pro,rain, threads need to operate as&nchrono!sl& /altho!,h
s&nchroni@in, 'hen accessin, shared data0, so the eittin, thread needs to post the
e%entsDessa,es to soe )!fferin, o)6ect 'here the recei%in, thread can fetch the
Cor threads r!nnin, in different %irt!al /or ph&sical0 achines, sendin, a essa,e
fro one thread to another cannot )e accoplished )& sipl& passin, a reference to
an e%ent o)6ect )et'een the threads. >ecall that o)6ect references /'hich are point -
ers 'ithin the address space of the :"-process0 ha%e a eanin, onl& 'ithin the pro-
,ra. Cor !lti- threaded pro,ras /'ithin one .U7D:"- process0 on the other hand,
'e can )!ild !pon the EventObject class entioned a)o%e. (o prepare for real- tie
pro,rai n,, ho'e%er, 'e need a ne' )ase class 'ith soe additions for real+time
e%ent o)6ects.
Real-Time Events – RTEvent
(he class se.lth.cs.realtime.event.RTEvent is the EventObject )ase class for
real- tie e%ents. >eal-tie here )asicall& eans that e%ents are time+ stamped ,
'hereas tr!e real- tie properties ha%e to do 'ith the properties of the e*ec!tin,
threads and their sched!lin,. <ence, real- tie e%ents 'ill )e needed )& real- tie
threads /introd!ced in a later chapter0, )!t the& are also !sef!l for !lti- threaded
pro,rai n, and for the co!nication )et'een conc!rrent and real- tie threads,
so introd!cin, the RTEvent class here for essa,e- )ased conc!rrenc& is nat!ral.
200E-01-11 15105 © ,)
Chapter 3 Multi-Threaded Programming
E%er& RTEvent coes fro a so!rce o)6ect referred to in the EventObject )ase class.
Additional 5Ds, s!ch as se2!ential n!)ers or the kind of e%ent 'ithin a certain
t&pe, are e*pected to )e defined in s!)classes to,ether 'ith other !ser attri)!tes.
(he tie stap is, ho'e%er, f!ndaent al to real- tie s&stes as a ean to denote
the freshness of the data. 5t is therefore an attri)!te here and the oti%ation for
this class.
(he source attri)!te, t&picall& )ein, a thread o)6ect, is not s!pposed to keep an&
reference to the e%ent after postin, it. (herefore, ethods of this class sho!ld not
need to )e s&nchroni@ed. (o s!pport detection of kept references, for instance 'hen
the e%ent is sent a,ain, there is a field owner 'hich is set to the sae as source
'hen the e%ent is created. 9hen an e%ent is transferred, for instance %ia a )!ffer,
the o'nership chan,es to the )!ffer and then to the recei%in, thread. $sin, a%ail -
a)le classes, the !ser sho!ld not need to care a)o!t the o'nership, it is checked to
detect certain pro,rain, errors. "oeties, ho'e%er, it is desira)le to keep a set
of e%ent o)6ects that are sent se%eral ties, for instance e%er& tie a certain state
transition occ!rs. 5n s!ch cases the specific e%ent s!)classes are s!pposed to set the
/protected0 o'ner field to null, 'hich disa)les the checkin, of o'nership.
>efer to the online class doc!entation for f!rther details. 5n short, ne,lectin, a fe'
feat!res for later chapters, the se.lth.cs.realtime.RTEvent class looks as1
public abstract
class RTEvent extends EventObject {
protected long timestamp; // Creation time in ms.
protected volatile transient Object owner; // Responsible thread.
public RTEvent(); // Use current Thread & TimeMillis.
public RTEvent(Object source); // Set source, default timestamp.
public RTEvent(long ts); // Set timestamp, default source
public RTEvent(Object source, long ts); // Override both defaults.
public final Object getOwner()
public double getSeconds()
public long getMillis()
public long getNanos()
(here is also a setOwner ethod, )!t that ethod is declared final and has pack -
a,e %isi)ilit& so it is of no interest for !ser code. "till, the !ser can in RTEvent s!)-
classes freel& odif& )oth the timestamp and owner attri)!tes. Cor instance, owner
can )e set to n!ll, and the timestamp can )e odified accordin, to an ipro%ed esti -
ation of a sapled inp!t data %al!e. (he o'ner does not need to )e a thread o)-
6ect, 'hich is !sef!l 'hen, e.,., re,!lator o)6ects in a control s&ste are dri%en )&
soe e*ternal thread; the e%ent- eittin, /)!t passi%e fro a .a%a point of %ie'0
control )lock can still )e the re,istered o'ner
of the o)6ect.
F (he concept of o'nership is taken fro the :"E operatin, s&ste fro
,* >eal- (ie Pro,rain, H a .a%a- )ased approach
Message-based communication – Mailboxes
(he owner attri)!te is declared volatile to perit thread- safe access e%ent fro
ethods not )ein, synchronized. 8oth source /fro java.util.EventObject0 and
owner are declared transient since those attri)!tes ha%e no eanin, o!tside the
pro,ra /.U70 'here the& 'ere created. 5nstead, for instance 'hen seriali@ed to a
strea of )&tes and sent o%er a net'ork, the& )oth ,et the %al!e null.
Real-Time Event Buffers – RTEventBuffer
(he class RTEventBuffer
is desi,ned to accoplish essa,e- )ased co!nication
'ith )!fferin, and !sin, RTEvent o)6ects as essa,es. (o a%oid conf!sion 'ith other
t&pes of )!ffers in other .a%a packa,es or in operatin, s&stes, the follo'in, sho!ld
)e clear1
1. (raditionall&, deands on fle*i)ilit& ha%e )een odest for real- tie and e)ed -
ded s&stes, and pro,rain, /in C0 'itho!t s!pport for o)6ect orientation has
)een standard. 7essa,es for co!nication are then in ost cases staticall& de-
fined )& soe struct t&pe. (he si@e of the essa,e can then )e o)tained )& call -
in, sizeof, no additional s!)classes are a%aila)le /or 'ill )e a%aila)le d!rin,
r!ntie0, the data is not s!)6ect to relocation )& soe eor& ana,er /BC0,
and therefore the essa,e can )e handled and copied as a se2!ence of )&tes.
9ith soe restrictions, the sae holds for pro,rain, in CJJ. A essa,e can
then )e referred to )& a pointer to the eor& location, )!t to ipro%e ro)!st -
ness for lar,e cople* s&stes the essa,e data is norall& copied for transfer
to soe other part of the soft'are. (he reason is that an!al eor& ana,e -
ent in ters of pro,rain, r!les and so called reference co!ntin, does not
scale !p %er& 'ell.

Cor !lti- threaded pro,rain, in .a%a, 'e do not kno' the o)6ect si@e or
'here the o)6ect is stored in eor&, and 'e do not ha%e to cop& essa,es for
reasons of eor& ana,eent /since .a%a pro%ides BC0. Postin, an e%ent o)-
6ect therefore eans passin, the /one 'ord0 reference to that o)6ect, 'hich also
sa%es the tie for the cop&in,.
2. (he RTEventBuffer is not !sef!l for co!nication )et'een :" processes1 the&
norall& 'ork in different address spaces and o)6ect references cannot )e shared,
and hence o)6ects are to )e represented )& data that is copied to the )!ffer. (he
actions to con%ert a .a%a o)6ect to a se2!ence of )&tes are referred to as seriali@a -
tion. (hat is s!pported in .a%a, partl& in ters of the interface
izable, )!t that is o!tside the scope of this chapter.
G (his )!ffer and the e%ent class RTEvent are part of the se.lth.cs.realtime.event
packa,e. #ike for the se.lth.cs.realtime.semaphore packa,e, the classes as
presented in this chapter are part of the #!nd .a%a- )ased >eal- (ie /#.>(0 li)rar& that
in ore detail 'ill )e the topic of the ne*t chapter. (he classes introd!ced in this chapter
add )asic !tilities for conc!rrent pro,rain,, 'itho!t chan,in, the odel of .a%a
threads and 'itho!t addin, real- tie s!pport. (hese classes are strai,htfor'ard to !se on
an& .a%a platfor, 'hereas the coplete #.>( li)rar& adds ore f!ndaental feat!res.
200E-01-11 15105 © ,,
Chapter 3 Multi-Threaded Programming
+. 8!ffers !sed for conc!rrent pro,rain,, s!ch as the java.util.Vector, are
!s!all& !n)o!nded. (hat is, the& e*pand in si@e 'hen f!ll, or a java.lang.Out-
OfMemoryError is thro'n. :!r ai at real- tie a'are conc!rrenc&, to prepare for
e%en hard real tie later, oti%ates soe care concernin, reso!rces, s!ch as
eor&. E%en if 'e for fle*i)le real- tie s&stes do not kno' e*actl& ho' an&
)&tes o!r application needs, 'e need soe )o!nds on the !sed reso!rces. Cor
)!fferin,, this eans that 'e 'ork 'ith bounded buffers as the defa!lt. 5f, in
soe cases, there sho!ld )e a need for !n)o!nded )!ffers, it is siple to o%erride
post or fetch ethods to e*pand the )!ffer si@e on deand.
:ther reasons for o!r o'n )!ffer ipleentation incl!de /copare 'ith java.u-
til.Vector01 shrinka,e 'itho!t losin, )!ffer content, s!pport for RTEvent and o)-
6ect o'nership, desi,n s!ita)le for e)eddedDnati%e ipleentation on sall- e-
or& s&stes, and licensin, iss!es for s!ch s&stes. Cor the p!rpose of s!)classin,,
the internals of the )!ffer is !sef!l to kno'; the se.lth.cs.realtime.even-
t.RTEventBuffer is ipleented as follo's.
"tora,e and s&nchroni@ation
"ince the )!ffer is to )e !sed
ainl& as a C5C: 2!e!e, 'ith a
)o!nded si@e that is norall& kept
constant, it is )est represented )&
an arra&. (hat is of co!rse not
%isi)le fro the o!tside, )!t to
s!)classes it is. 9hen the inde*
needs to ad%ance )e&ond the
a*i! inde* of the arra& it flips
o%er and contin!es at inde* @ero.
(herefore this t&pe of )!ffer is also
called rin, )!ffer, as depicted in
Ci,!re +-10.
(he ethods of the )!ffer co!ld )e
considered )ein, synchronized,
that is, the )!ffer is thread safe. (o
pre%ent interference 'ith
waitDnotify internall& fro
e*ternal code s&nchroni@in, on the
)!ffer o)6ect, the s&nchroni@ation of
the )!ffer ethods are accoplished )&
'here the lock is declared as
protected Object lock = new Object();
(hat onitor lock can then )e replaced in s!)classes or in the constr!ctor, if
the operation of the )!ffer needs to )e s&nchroni@ed 'ith soe other o)6ects
/s!ch as an other )!ffer0.
(he act!al )!fferDarra& is, as sho'n in Ci,!re +-10, declared as
,0 >eal- (ie Pro,rain, H a .a%a- )ased approach
Ci,!re +-10 >in, )!ffer as an arra& 'ith
si@e 12, c!rrentl& filled 'ith F o)-
6ects /referenced fro the ,ra& ele-
RTEvent[] buffer
Message-based communication – Mailboxes
protected RTEvent[] buffer;
A ne' )!ffer is created )& the follo'in, constr!ctors, 'here the defa!lt
maxSize is soe s&ste dependent DEFAULT_SIZE /c!rrentl& E4 in o!r
s&ste0, and the defa!lt lock o)6ect is allocated and internall&. (he
paraeters maxSize and lock o%errides the defa!lts1
public RTEventBuffer()
public RTEventBuffer(int maxSize)
public RTEventBuffer(int maxSize, Object lock)
(he ethods for postin, e%ents to the )!ffer are naed doPost, tryPost, or
sipl& post. (he doPost ethod sipl& )locks the caller !ntil the postin, is
copleted. (he tryPost ,i%es !p if the )!ffer is f!ll, either iediatel& if no
tieo!t is ,i%en or after the specified timeout /in s0. (he ethod post is the
,eneric one that is s!)6ect to replaceent in s!)classes, 'hereas the other
ethods are declared final for reasons of efficienc&.
(he post ethod )& defa!lt sipl& calls doPost and ret!rns null. (he ret!rn
/of t&pe RTEvent0 %al!e is !sef!l 'hen s!)classin, and chan,in, post to call
one of the tryPost ethods, 'hich ret!rn null 'hen the e%ent 'as
s!ccessf!ll& posted. (he e%ent s!pplied as an ar,!ent to tryPost is ret!rned
if not posted /d!e to the )!ffer )ein, f!ll0. >et!rnin, the !nposted e%ent
siplifies the callin, code. (he p!)lic postin, ethods are1
RTEvent post(RTEvent e)
final void doPost(RTEvent e)
final RTEvent tryPost(RTEvent e)
final RTEvent tryPost(RTEvent e, long timeout)
(he correspondin, ethods for fetchin, essa,es look as follo's, 'here the
tryFetch ethods ret!rn null if no e%ent o)6ect 'as o)tained.
RTEvent fetch()
final RTEvent doFetch()
final RTEvent tryFetch()
final RTEvent tryFetch(long timeout)
Control and stat!s
(he follo'in, non- )lockin, ethods can )e !sed to check if the )!ffer is ept&
or f!ll.
boolean isEmpty()
boolean isFull()
Cor a sin,le prod!cin, or cons!in, thread these ethods can )e !sef!l, )!t
in the ,eneral case 'ith o!ter threads in%ol%ed the ret!rned state a& of
co!rse )e in%alid alread& 'hen e*ec!tion contin!es on the ne*t line /d!e to
preeption, etc.0, so !sin, the try-ethods are !s!all& preferred.
"oeties state or ode chan,es are to take place )ased on the state of the
200E-01-11 15105 © ,2
Chapter 3 Multi-Threaded Programming
)!ffer, and the responsi)le thread is to )e )locked !ntil the )!ffer condition is
f!lfilled. (he follo'in, a'ait- ethods are )lockin,. E*aples of !se incl!de1
a'ait all e%ent cons!ed )efore terinatin, the application, a'ait prod!cer
started )efore startin, operator or net'orkin, interface, a'ait )!ffer filled
'ith e%ent trace, and a'ait cons!er started, respecti%el&1
void awaitEmpty()
void awaitNotEmpty()
void awaitFull()
void awaitNotFull()
(he fetchAll is to ,et all )!ffered e%ents lea%in, the )!ffer ept&. (he e%ent
that 'as the ne*t to )e fetched is ret!rned as the first eleent /inde* 00,
follo'ed )& the other e%ents in C5C: order 'ith the ost recentl& posted e%ent
as the last eleent. An ept& arra& /not n!ll0 is ret!rned if the )!ffer 'as
ept&. Callin, flush also res!lts in an ept& )!ffer.
RTEvent[] fetchAll()
void flush()
(here are set and get ethods for the a*i! si@e of the )!ffer. Note that
if the a*i! si@e of the )!ffer is decreased to less than the c!rrent si@e
/o)tained %ia currentSize0, the caller of setMaxSize is )locked !ntil the si@e
act!all& has decreased to the ne' a*i! si@e /d!e to other threads fetchin,
int currentSize()
public int getMaxSize()
void setMaxSize(int newSize)
:ther protected fields
Apart fro the protected )!ffer arra& and o)6ect lock descri)ed a)o%e, the
follo'in, are the other fields for s!)class !sa,e. Cirst there are the inde*es for
readin, respecti%el& 'ritin, as sho'n in Ci,!re +-10, as 'ell as the c!rrent
int currSize;
int postAt;
int fetchAt;
(here are t'o fields for keepin, the a*i! si@e. 5t is the maxSizeW that is
the re2!ested a*i! si@e. (he maxSizeR can teporaril& d!rin, shrinka,e
/resizing e2!al to true0 of a too lar,e )!ffer )e ,reater than maxSizeW, )!t
the& 'ill ha%e the sae %al!e d!rin, noral operation /'hen resizing e2!als
int maxSizeR;
int maxSizeW;
boolean resizing;
(hreads that are interr!pted d!rin, /or prior to0 )lockin, are thro'n an RTInter-
rupted error.
06 >eal- (ie Pro,rain, H a .a%a- )ased approach
Message-based communication – Mailboxes
Referring to buffer input or output
"oeties it is desira)le to ha%e an o)6ect that represents onl& one end of a )!ffer.
Cor the RTEventBuffer, !tili@in, .a%a interfaces, this is accoplished )& one inter -
face for inp!t containin, the post ethods, and one interface for o!tp!t containin,
the ethods for fetchin, e%ents. (h!s,
class RTEventBuffer implements RTEventBufferInput, RTEventBufferOutput

'here these interfaces are defined as
interface RTEventBufferInput {
RTEvent post(RTEvent e);
void doPost(RTEvent e);
RTEvent tryPost(RTEvent e);
RTEvent tryPost(RTEvent e, long timeout);
RTEvent tryPost(RTEvent e, long timeout, int nanos);
interface RTEventBufferOutput {
RTEvent fetch();
RTEvent doFetch();
RTEvent tryFetch();
RTEvent tryFetch(long timeout);
RTEvent tryFetch(long timeout, int nanos);

>efer to the RTEventBuffer a)o%e for a description of the ethods. $sin, these in-
terfaces &o! can for instance ha%e the o!tp!t of a )!ffer ana,ed as a shared re-
so!rce in a onitor, 'hile the inp!t can )e directl& a%aila)le for postin, e%ents
/fro se%eral threads since the RTEventBuffer )& itself is a onitor0. 9ithin s!ch a
onitor holdin, an RTEventBufferInput, a potentiall& )lockin, call s!ch as doFetch
sho!ld onl& )e !sed 'ith ,reat care since the )locked thread 'ill lock also the o!ter
5n ,eneral for prod!cer- cons!er sit!ations, the inp!t and o!tp!t interfaces to the
)!ffer sipl& pro%ide a con%enient 'a& of passin, one end of the )!ffer to the pro-
d!cer or the cons!er. :f co!rse an o)6ect /a onitor or an ordinar& o)6ect0 ,i%en an
RTEventBufferInput can check if it is an instance of RTEventBuffer /'hich it does
not need to )e since an& o)6ect can ipleent the sae interface0, and if so, cast to
RTEventBuffer and !se also the post ethods. <ence, these interfaces are pro%ided
for con%enience for certain pro,rain, sit!ations in%ol%in, cooperatin, o)6ects,
)!t as !s!all&, is!se can )e ade c!)ersoe )!t not copletel& pre%ented. >e-
call, ho'e%er, that !lti- threadin, ainl& is a)o!t cooperatin, conc!rrenc&.
200E-01-11 15105 © 01
Chapter 3 Multi-Threaded Programming
Threads and event-based communication
A ail)o*, here accoplished )& an instance of RTEventBuffer
, can )e declared and
referred to in different 'a&s1
• (he ail)o*/es0 can )e ade ,lo)all& a%aila)le, for e*aple created in the ain
pro,ra and passed as ar,!ent to the constr!ctors of the different sendin,Dre -
cei%in, o)6ects/ t&picall& threads0, or staticall& defined attri)!tes of soe class
kno'n to other classes at copile tie. 9ith s!ch ,lo)all& defined ail)o*es,
the& are %isi)le in the soft'are desi,n, as entities of their o'n.
• 9e can also %ie' the pro%ided )!fferin, as a propert& of soe o)6ect, and ha%e
the ail)o* as an attri)!te internal to the class that pro%ides the ethods that
ake !se of the )!fferin,. (&picall& the enclosin, class 'ill )e of t&pe Thread and
act as the recei%er of the e%ents /altho!,h the sender can )e !na'are of that if
sendin, is accoplished )& soe other ethod of the recei%in, thread. 9ith s!ch
o)6ect-internal ail)o*es, the )!fferin, is part of the internal desi,n of that class.
(h!s, the the ain difference here is a desi,n choice1 sho!ld ail)o*es )e e*posed-
to or part- of the o)6ects that ake !se of theM Collo'in, coon o)6ect-oriented
desi,n r!les, this depends on 'hat 'e see as entities 'ithin o!r desi,n. 5f the
)!ffers for the core of the application it a& )e prefera)le to ha%e the e*posed.
<o'e%er, in ost cases the )!ffers are introd!ced to deco!ple the e*ec!tion, that is,
to ake o)6ect interaction as&nchrono!s )!t still )ased on the ethods at hand.
<ence, the noral case is to hide the ail)o* as an attri)!te inside the o)6ect.
(here is a s!)class of Thread that pro%ides this feat!re, nael& class se.lth.c-
The featured Java Thread class – JThread
(o s!pport the ost coon case that the ail)o* in ters of an RTEventBuffer is
handled locall& 'ithin the recei%in, thread, and encaps!lated )& the ethods of
that thread, class se.lth.cs.realtime.JThread contains the follo'in, /see
volatile on Pa,e 5I01
public class JThread extends java.lang.Thread
/** The event inbut buffer. */
protected volatile RTEventBuffer mailbox;
* Put the time-stamped event in the input buffer of this thread.
* If the buffer is full, the caller is blocked.
I (he !pcoin, ne' release of the #.>( classes 'ill incl!de )oth the RTEventBuffer and
other )!ffer classes 'ith different properties and different ipleent ations. (he .a%a- doc
pa,es pro%ide the %alid description for pro,rain, !sin, the a%aila)le )!ffers, 'hile the
/not coplete0 description here co%ers the ,eneral ideas of e%ents and )!ffers.
0' >eal- (ie Pro,rain, H a .a%a- )ased approach
Message-based communication – Mailboxes
public RTEvent putEvent(RTEvent ev) {
mailbox.doPost(ev); // Subclasses may use tryPost.
return null; // Subclasses may return resulting event.
// etc. etc.
(he J in JThread is to stress the fact that this t&pe of thread still is a /conc!rrent0
.a%a thread /that is, not specified to )e real tie as 'ill )e the case in follo'in,
(o siplif& pro,rai n, in the case that the sae thin, sho!ld )e repeated o%er
and o%er a,ain, there is a defa!lt r!n ethod that calls perfor accordin, to the fol-
public void run() {
while (!isInterrupted()) {
9hen ipleentin, the thread )eha%ior, in run or perform, the the doFetch and
tryFetch ethods are !sef!l, like is this e*eplif&in, perform ethod1
class MyEventProcessor extends JThread
public void perform()
5n addition to the ethods of the )ase class Thread as sho'n on Pa,e 41, this eans
that the class JThread pro%ides the follo'in, siple to ipleent )!t con%enient
RTEvent putEvent(RTEvent ev) // Generic event input
void terminate() // Interrupt and join
public static
void sleepUntil(long wakeUpTime) // Sleep until that absolute time
void perform() // Override to define cyclic work
200E-01-11 15105 © 03
(o )e accoplished.....

Sign up to vote on this title
UsefulNot useful