Distributed embedded and real time java systems 2012th edition m teresa higuera toledano andy j well

Visit to download the full and correct content document: https://textbookfull.com/product/distributed-embedded-and-real-time-java-systems-20 12th-edition-m-teresa-higuera-toledano-andy-j-wellings/

More products digital (pdf, epub, mobi) instant download maybe you interests ...

Embedded Systems VOL. 3: Real-Time Operating Systems for ARM Cortex-M Microcontrollers Jonathan Valvano

https://textbookfull.com/product/embedded-systems-vol-3-realtime-operating-systems-for-arm-cortex-m-microcontrollersjonathan-valvano/

Distributed Real Time Architecture for Mixed Criticality Systems 1st Edition Hamidreza Ahmadian (Editor)

https://textbookfull.com/product/distributed-real-timearchitecture-for-mixed-criticality-systems-1st-edition-hamidrezaahmadian-editor/

Linear Discrete-Time Systems Zoran M. Buchevats

https://textbookfull.com/product/linear-discrete-time-systemszoran-m-buchevats/

Energy Autonomy of Real-Time Systems Maryline Chetto And Audrey Queudet (Auth.)

https://textbookfull.com/product/energy-autonomy-of-real-timesystems-maryline-chetto-and-audrey-queudet-auth/

Cloud FinOps Collaborative Real Time Cloud Financial Management 1st Edition J. R. Storment

https://textbookfull.com/product/cloud-finops-collaborative-realtime-cloud-financial-management-1st-edition-j-r-storment/

Embedded System Design : Embedded Systems, Foundations of Cyber-Physical Systems, and the Internet of Things Marwedel

https://textbookfull.com/product/embedded-system-design-embeddedsystems-foundations-of-cyber-physical-systems-and-the-internetof-things-marwedel/

Dependable Embedded Systems Jörg Henkel

https://textbookfull.com/product/dependable-embedded-systemsjorg-henkel/

Building Machine Learning Systems with a Feature Store: Batch, Real-Time, and LLM Systems (Early Release) Jim Dowling

https://textbookfull.com/product/building-machine-learningsystems-with-a-feature-store-batch-real-time-and-llm-systemsearly-release-jim-dowling/

Embedded System Design: Embedded Systems Foundations of Cyber-Physical Systems, and the Internet of Things. 4th Edition Peter Marwedel

https://textbookfull.com/product/embedded-system-design-embeddedsystems-foundations-of-cyber-physical-systems-and-the-internetof-things-4th-edition-peter-marwedel/

Editors

M.TeresaHiguera-Toledano

UniversidadComplutensedeMadrid FacultaddeInform ´ atica,DACYA

CalledelProfesorGaec´ıa Santesmas

28040Madrid

Spain

AndyJ.Wellings DepartmentofComputerScience

UniversityofYork Heslington York UnitedKingdom

ISBN978-1-4419-8157-8e-ISBN978-1-4419-8158-5 DOI10.1007/978-1-4419-8158-5 SpringerNewYorkDordrechtHeidelbergLondon

LibraryofCongressControlNumber:2011945437

©SpringerScience+BusinessMedia,LLC2012

Allrightsreserved.Thisworkmaynotbetranslatedorcopiedinwholeorinpartwithoutthewritten permissionofthepublisher(SpringerScience+BusinessMedia,LLC,233SpringStreet,NewYork, NY10013,USA),exceptforbriefexcerptsinconnectionwithreviewsorscholarlyanalysis.Usein connectionwithanyformofinformationstorageandretrieval,electronicadaptation,computersoftware, orbysimilarordissimilarmethodologynow knownorhereafterdevelopedisforbidden. Theuseinthispublicationoftradenames,trademarks,servicemarks,andsimilarterms,eveniftheyare notidentifiedassuch,isnottobetakenasanexpressionofopinionastowhetherornottheyaresubject toproprietaryrights.

Printedonacid-freepaper

SpringerispartofSpringerScience+BusinessMedia(www.springer.com)

Preface

TheJavalanguagehashadanenormousimpactsinceitsintroductioninthelast decadeofthetwentiethcentury.Itssuccesshas beenparticularlystronginenterprise applications,whereJavaisoneofthepreeminenttechnologyinuse.Adomain whereJavaisstilltryingtogainafootholdisthatofreal-timeandembedded systems,betheymulticoreordistributed.Overthelast5years,thesupportingJavarelatedtechnologies,inthisincreasinglyimportantarea,havematured.Somehave maturedmorethanothers.Theoverallgoalofthisbookistoprovideinsightsinto someofthesetechnologies.

Audience

Thisbookisaimedatresearchersinreal-timeembeddedsystems,particularlythose whowishtounderstandthecurrentstateoftheartinusingJavainthisdomain. Mastersstudentswillalsofindusefulmaterialthatfoundsbackgroundreadingfor higherdegreesinembeddedandreal-timesystems.

StructureandContent

Muchoftheworkinreal-timedistributed,embeddedandreal-timeJavahasfocused ontheReal-timeSpecificationforJava(RTSJ)astheunderlyingbasetechnology, andconsequentlymanyoftheChaptersinthisbookaddressissueswith,orsolve problemsusing,thisframework.

Real-timeembeddedsystemarealsothemselvesevolving.Distributionhas alwaysbeenanimportantconsideration,butsingleprocessornodesarerapidly beingreplacedbymulticoreplatforms.Thishasincreasedtheemphasisonparallelprogrammingandhashadamajorimpactonembeddedandreal-time softwaredevelopment.Thenextthreechapters,therefore,exploreaspectsofthis

issue.InChap. 1,Wellings,DibbleandHolmesdiscusstheimpactofmulticoreontheRTSJitselfandmotivatewhyVersion1.1ofthespecificationwill havemoresupportfor multiprocessors.Centralto thissupportisthenotionof processoraffinity.

RTSJhasalwaysremainedsilentonissuesofdistributedsystemasotherwork intheJavaCommunityhasbeenaddressingthisproblem.Unfortunately,thiswork hasbeenmoribundforseveralyearsandisnowconsideredinactive.Itis,therefore, anappropriatetimetore-evaluatetheprogressinthisarea.InChap. ,Basanta-Val andAndersonreviewsthestateoftheartindistributedreal-timeJavatechnology consideringboththeproblemsandthesolutions.

Asembeddedreal-timesystemgrowinsize,theywillbecomemorecomplex andhavetocopewithamixtureofhardandsoftreal-timesystems.Scheduling thesesystems,withintheimposedtimeconstraints,isachallengingproblem.Of particularconcernishowtointegrateaperiodiceventsintothesystem.Theaccepted theoreticalworkinthisarearevolvesaroundtheusageofexecution-timeservers.In Chap. 3,MassonandMidonnetconsiderhowtheseserverscanbeprogrammedin theRTSJattheapplicationlevel.

Irrespectiveofsize,embeddedsystemshaveimposedconstraints,betheypower consumption,heatdissipationorweight.Thisresultsintheresourcesintheplatform beingkepttoaminimum.Consequently,theseresourcesmustbecarefullymanaged. Processorsandnetworksarethetwoofthemainresourcetypes,andhavebeen consideredinChaps. 1–3.Memoryistheothermainresource,anditisthisthatis thetopicofChap. 4 throughChap. 6.Real-timegarbagecollectioniscrucialtothe successofreal-timeJavaandtheadventofmulticorehasaddednewimpetusto thattechnologytoproduceparallelcollectors.InChap. 4,Siebertexplainsthebasic conceptsbehindparallelcollectorsandreviewstheapproachestakenbythemajor RTSJimplementations.

RTSJintroducedaformofregion-basedmemorymanagementasanalternative totheuseoftheheapmemory.Thishasbeenoneofthemostcontroversialfeatures ofthespecification.Forthisreason,Higuera-Toledano,Yovine,andGarbervetsky (inChap. 5)evaluatetheroleofregion-basedmemorymanagementintheRTSJand lookatthestrengthsandweaknessesoftheassociatedRTSJscopedmemorymodel. Thethirdaspectofmemorymanagementforembeddedsystemsishowtoaccess theunderlyingplatform’sphysicalmemory–inordertomaximizeperformance andinteractwithexternaldevices.Thishasalwaysbeenadifficultareaandonethat hasbeensubstantiallyrevisedinRTSJVersion1.1.InChap. 6,Dibble,Huntand Wellingsconsiderstheselow-levelprogrammingactivities.

Partandparcelofdevelopingembeddedsystemsisdecidingonthedemarcation betweenwhatisinsoftwareandwhatisinhardware.FromaJavaperspective,there aretwoimportanttopics:hardwaresupportfortheJVMandhowapplicationscall codethathasbeenimplementedinhardware.Thesetwoissuesareaddressedin Chaps. 7 and 8.InChap. 7,Schoeberlreviewstheapproachesthathavebeentakento supporttheexecutionforJavaprograms.Thisincludesimportantareaslikesupport fortheexecutionofJavabytecodeandgarbagecollection.Incontrast,Whithamand

AudsleyinChap. 8,focusontheinteractionbetweenJavaprogramsandfunctional acceleratorsimplementedascoprocessorsorinFPGAs. Embeddedsystemsareubiquitousandincreasinglycontrolvitaloperations. Failureofthesesystemshaveanimmediate,andsometimescatastrophic,impact onsociety’sabilitytofunction.ProponentsofJavatechnologyenvisageagrowing roleforJavainthedevelopmentofthesehigh-integrity(oftensafety-critical) systems.AsubsetofJavaaugmentedwiththeRTSJ,calledSafetyCriticalJava (SCJ)iscurrentlybeingdevelopedbytheJavaCommunityProcess.Thiswork isapproachingfruitionandtwoofthemostimportantaspectsarediscussed inChaps. 9 and 10.Mostembeddedandreal-timesystemdirectlyorindirectly supportthenotionofamission.IntheRTSJ,thisnotioncanbeimplementedbut thereisnotdirectrepresentation.SCJprovidesdirectsupportforthisconcept. InChap. 9,NielsenandHuntdiscussthemissionconceptandshowhowitcan beused.Paramounttohigh-integrityapplicationsisreliability.AlthoughJava isastronglytypedlanguagerun-timeexceptionscanstillbegenerated.Recent versionsofthelanguagehaveaddedsupportforannotations,whichessentially allowaddedinformationtobepassedtothecompiler,developmenttoolssupportingstaticanalysis,andtheJVMitself.InChap. 10,Tang,PlsekandJan VitekexploretheSCJuseofannotationstosupportmemorysafety,thatis theabsenceofrun-timeexceptionsresultingfromviolationsoftheSCJmemorymodel.

Upuntilnow,thetopicsthathavebeenaddressedhavebeenconcernedwith theunderlyingtechnologyforreal-timeandembeddedJava.Theremainderofthe bookfocusesonhigherlevelissues.Real-timeandembeddedsystemdesigners havetobemoreresource-awarethantheaverageJavaprogrammer.Inevitably, thisleadstocomplexitiesintheprogrammingtask.TheRTSJhasintroduced abstractionsthathelptheprogrammermanageresources;however,someofthese abstractioncanbedifficulttouse(forexample,scopedmemory).InChap. 11, Plsek,LoiretandMalohlavaarguethatthiscanmaketheuseoftheRTSJerror prone.TheyconsidertheroleofRTSJ-awarecomponent-orientedframeworksthat canhelpprovideaclearerseparationbetweenRTSJ-relatedissuesandapplicationrelatedissues.

Onewell-knownJavaframeworkforcomponent-basedservice-orientedarchitecturesistheOpenServicesGatewayinitiative(OSGi).Althoughthis initiative haswidesupportfromindustry,itlacksanysupportforreal-timeapplications.In Chap. 12,RichardsonandWellingsproposetheintegrationofOSGiwiththeRTSJ toprovideareal-timeOSGiframework.

Inthefinalchapterofthisbook,Holgado-TerrizaandVidez-Aivaraddressthe issueofbuildingacompleteembeddedapplicationthatincludesbothsoftwareand hardwarecomponentsfromareusablebase.

Acknowledgements

TheeditorsaregratefultoSpringerwhogaveustheopportunitytoproducethis book,andtoalltheauthorsforagreeingtocontribute(andforreviewingeachothers chapters).

WearealsoindebtedtoSitsofeWheelerforhishelpwithlatex.

Contents

1SupportingMultiprocessorsintheReal-Time SpecificationforJavaVersion1.1 .........................................1 AndyJ.Wellings,PeterDibble,andDavidHolmes

2UsingReal-TimeJavainDistributedSystems:Problems andSolutions ................................................................23 PabloBasanta-ValandJonathanStephenAnderson

3HandlingNon-PeriodicEventsinReal-TimeJavaSystems ...........45 DamienMassonandSergeMidonnet

4ParallelReal-TimeGarbageCollection ..................................79 FridtjofSiebert

5Region-BasedMemoryManagement:AnEvaluation ofItsSupportinRTSJ .....................................................101 M.TeresaHiguera-Toledano,SergioYovine, andDiegoGarbervetsky

6ProgrammingEmbeddedSystems:Interacting withtheEmbeddedPlatform ..............................................129 PeterDibble,JamesJ.Hunt,andAndyJ.Wellings

7HardwareSupportforEmbeddedJava ..................................159 MartinSchoeberl

8InterfacingJavatoHardwareCoprocessorsandFPGAs ..............177 JackWhithamandNeilAudsley

9Safety-CriticalJava:TheMissionApproach ............................199 JamesJ.HuntandKelvinNilsen

10MemorySafetyforSafetyCriticalJava ..................................235 DanielTang,AlesPlsek,andJanVitek

11Component-OrientedDevelopmentforReal-TimeJava

AlesPlsek,FredericLoiret,andMichalMalohlava

12RT-OSGi:IntegratingtheOSGiFramework withtheReal-TimeSpecificationforJava ...............................293 ThomasRichardsonandAndyJ.Wellings

13JavaES,aFlexibleJavaFrameworkforEmbeddedSystems ..........323 JuanAntonioHolgado-TerrizaandJaimeVi´udez-Aivar

References

Chapter1 SupportingMultiprocessorsintheReal-Time SpecificationforJavaVersion1.1

AndyJ.Wellings,PeterDibble,andDavidHolmes

Abstract Version1.1oftheReal-TimeSpecificationforJava(RTSJ)hassignificantlyenhanceditssupportformultiprocesso rplatforms.Thischapterdiscusses therationalefortheapproachadoptedandpresentsdetailsoftheimpactonthe specification.Inparticular,itconsidersthenewdispatchingandprocessoraffinity models,issuesofcostenforcementandtheaffinityofexternalevents.

1.1Introduction

Multiprocessorplatforms(betheymulticoreormultichipsystems)1 arebecoming moreprevalentandtheirroleintheprovisionofawidevarietyofreal-timeand embeddedsystemsisincreasing.Inparticularsymmetricmultiprocessor(SMP) systemsarenowoftenthedefaultplatform forlargereal-timesystemsratherthana singleprocessorsystem.

1 Theterm processor isusedinthischaptertoindicatealogicalprocessingelementthatiscapable ofphysicallyexecutingasinglethreadofcontrolatanypointintime.Hence,multicoreplatforms havemultipleprocessors,platformsthatsupporthyperthreadingalsohavemorethanoneprocessor. Itisassumedthatallprocessorsarecapableofexecutingthesameinstructionsets.

A.J.Wellings( ) DepartmentofComputerScience,UniversityofYork,York,UK e-mail: andy@cs.york.ac.uk

P.Dibble TimeSys,Pittsburgh,PA,USA e-mail: peter.dibble@timesys.com

D.Holmes 17WindwardPlace,JacobsWell,QLD4208,Australia

e-mail: dholmes@ieee.org

M.T.Higuera-ToledanoandA.J.Wellings(eds.), Distributed,Embedded andReal-timeJavaSystems,DOI10.1007/978-1-4419-8158-5 1, ©SpringerScience+BusinessMedia,LLC2012

Sinceitsinception,theReal-TimeSpecification(RTSJ)haspreferredtoremainsilentonmultiprocessorissues.Itallowsvendorstosupportmultiprocessor implementations,butprovidesnoguidelinesonhowthespecificationshouldbe interpretedinthisarea.Furthermore,itprovidesnoprogrammingabstractionsto helpdevelopersconfiguretheirsystems.ThelatestversionoftheRTSJrecognizes thatthispositionisnolongertenable.However,multiprocessor,andmulticore architecturesinparticular,areevolving atabewilderingrate,andOperatingSystem Standards(inparticularthesuiteofPOSIXStandards)haveyettocatchup. Consequently,itisdifficulttodeterminethelevelofsupportthatthespecification shouldtarget.Thisiscompoundedbytherequirementtostayfaithfultotheguiding principlesthathavedelimitedthescopeoftheRTSJ.Theseinclude[65]:

•Predictableexecutionasthefirstpriorityinalltradeoffs.

•Writeonce,runanywherebutnotattheexpenseofpredictability(laterrephrased to“writeoncecarefully,runanywhereconditionally”).

•Addresscurrentpracticebutallowfutureimplementationstoincludeenhanced features.

•Allowvariationsinimplementationdecisions.

Thischapterisstructuredasfollows.InSect. 1.2,themotivationsforproviding moredirectsupportformultiprocessors intheRTSJisgivenalongwiththe constraintsimposedbytheRTSJguidingprinciples.Inthemajorityofcases, theRTSJrun-timeenvironmentexecutesasmiddlewareontopofanunderlying operatingsystem.Thefacilitiesprovidedbytheseoperatingsystemsconstrain furtherthepossiblesupportthespecificationcanprovide.Section 1.3 reviews thesupportthatistypicalofcurrentoperatingsystemsinwidespreaduse.These motivationsandconstraintsareusedtogenerate,inSect. 1.4,alistofmultiprocessor requirementsfortheRTSJVersion1.1.Then,inSect. 1.5,thefullsupportfor multiprocessorsystemsintheRTSJversion1.1isdiscussed.Finally,conclusions aredrawn.AnappendixdetailsthenewAPI.

1.2MotivationsandConstraints

Whilstmanyapplicationsdonotneedmorecontroloverthemappingofschedulable objects2 toprocessors,thereareoccasionswhensuchcontrolisimportant.Here thefocusisonsymmetricmultiprocessor(SMP)systems,whicharedefinedto beidenticalmultiprocessorsthathaveaccesstosharedmainmemorywitha uniformaccesstime.Theimpactofnonuniformmemoryarchitecturesisleftfor futureversionsofthespecification,asareheterogeneousprocessorarchitectures orsystemswithhomogeneousprocessorarchitectureswithdifferentperformance characteristics.

2 TheRTSJusesthegenerictermschedulableobjectwhereotherlanguagesandoperatingsystems mightusethetermreal-timethreadortask.

1.2.1Motivation:ToObtainPerformanceBenefits

Theprimarymotivationformovingfromasingleprocessortoamultiprocessor implementationplatformistoobtainanincreaseinperformance.Dedicatingone CPUtoaparticularschedulableobjectwillensuremaximumexecutionspeedfor thatschedulableobject.RestrictingaschedulableobjecttorunonasingleCPU alsopreventstheperformancecostcau sedbythecache(TLBorothernon-memory relatedcontextassociatedwiththeschedulableobject)invalidationthatoccurswhen aschedulableobjectceasestoexecuteon oneCPUandthenrecommencesexecution onadifferentCPU[251].Furthermore,configuringinterruptstobehandledona subsetoftheavailableprocessorsallows performance-criticalschedulableobjects torununhinderedonotherprocessors.

1.2.2Motivation:ToSupportTemporalIsolation

Whereanapplicationconsistsofsubsystemsofmixedcriticalitylevels(non-critical, mission-criticalandsafety-critical)runningonthesameexecutionplatform,some formofprotectionbetweenthedifferentlevelsisrequired.Thestricttypingmodel ofJavaprovidesstrongprotectioninthespatialdomain.TheCostEnforcement ModeloftheRTSJ(includingprocessinggroupparameters)providesalimited formoftemporalprotectionbutisoftenverycoarsegrained.Morereliable temporalprotectionisobtainablebypartitioningthesetofprocessorsandallowing schedulableobjectsineachcriticalityleveltobeexecutedinaseparatepartition. Forexample,placingallnon-criticalschedulableobjectsinaseparatepartitionwill ensurethatanyoverrunsoftheselesscriticalschedulableobjectscannotimpacta high-criticalitysubsystem.

1.2.3Constraint:PredictabilityofScheduling

Theschedulingofthreadsonmultiprocessorsystemscanbe:

1.Global–allprocessorscanexecuteallschedulableobjects.

2.Fullypartitioned–eachschedulableobjectisexecutedonlybyasingleprocessor;thesetofschedulableobjectsispartitionedbetweenthesetofprocessors.

3.Clustered–eachschedulableobjectcanbeexecutedbyasubsetoftheprocessors;hencetheschedulableobjectssetmaybepartitionedintogroupsandeach groupcanbeexecutedonasubsetoftheprocessors.

Inadditiontotheabove,therearehybridschemes.Forexample,semipartitioned schemesfixedthemajorityofschedulableobjectstoindividualprocessorsbutallow theremaindertomigratebetweenprocessors(sometimeatfixedpointsintheir executions).Thesituationcanbecomeevenmorecomplexiftheplatformcanvary thenumberofprocessorsavailableforexecutionoftheprogram.

Althoughthestateoftheartinschedulabilityanalysisformultiprocessorsystems continuestoadvance[26,121],itisclearthatforfixedpriorityscheduling,neither globalnorfully-partitionedsystemsareoptimal.Thereisnoagreedapproach andthewell-knownsingleprocessorschedulingalgorithmsarenotoptimalina multiprocessorenvironment.Cluster-basedschedulingseemsessentialforsystems withalargenumberofprocessors.However,withincluster,hybridapproachesallow greaterutilizationtobeachievedoverglobalschedulingwithincluster[121].

Hence,itisnotpossiblefortheRTSJtoprovideadefaultpriority-based multiprocessorschedulerthattakescareoftheallocationofschedulableobjects toprocessors.Andevenifitwas,itwouldrequireaveryspecializedreal-time operatingsystemtosupportit.

1.2.4Constraint:PredictabilityofResourceSharing

GiventhediscussioninSect. 1.2.3,itishardlysurprisingthatthesharingof resources(sharedobjects)betweenschedulableobjects,whichpotentiallycanbe executingondifferentprocessors,isproblematic.Theessenceoftheproblemis howtodealwithcontentionforglobalresources;howtokeepthedatacoherentand howtoboundthetimethataschedulableobjectwaitsforaccesstoit.

Overthelast40years,manydifferentapproacheshavebeenexplored.One approachthathasmaintaineditspopularityovertheyears(andwhichhasprovided theinspirationfortheJavamodel)isthemonitor.Amonitorencapsulatesashared resource(usuallysomesharedvariables)andprovidesaprocedural/functional interfacetothatresource.

InJava,amonitorisanobjectwiththeimportantpropertythatthemethodsthat arelabeledassynchronizedareexecutedatomicallywithrespecttoeachother.This meansthatonesynchronizedmethodcallcannotinterferewiththeexecutionof anothersynchronizedmethod.Thewaythisisachieved,inpractice,isbyensuring thatthecallsareexecutedinmutualexclusion.Thereareseveraldifferentways ofimplementingthis,forexample,byhavingalockassociatedwiththemonitor andrequiringthateachmethodacquires(sets)thelockbeforeitcancontinueits execution.Lockscanbe suspension-based or spin-based. Fromamultiprocessorreal-timeperspective,thefollowingtypicallyapply.

•Suspension-basedlocking –ifitcannotacquirethelock,thecallingschedulable objectisplacedinapriority-orderedqueueandwaitsforthelock.Toboundthe blockingtime,priorityinversionavoidancealgorithmsareused.

•Spin-basedlocking–ifitcannotacquirethelock,thecallingschedulableobject busy-waitsforthelocktobecomeavailable.Toboundtheblockingtime,the schedulableobjectnormallyspinsnon-preemptively(i.e.,atthehighestpriority) andisplacedinaFIFOorpriority-orderedqueue.Thelock-owneralsorunsnonpreemptively,andconsequentlyisprohibitedfromaccessingnestedlocksand mustnotsuspendwhilstholdingalock.

Ofcourse,optimizationsarepossible,suchasallowingthelocktoonlybe acquiredwhencontentionactuallyoccurs,orinitiallyspinningforthelockbefore suspending[172].Onasingleprocessorsystemitisalsopossibletoturnoffall hardwareinterruptswhilstholdingthelock,andthereforeprohibitanyscheduling preemptions.

Mutualexclusionisaveryheavy-weightmechanismtomaintaindataconsistency.Itreducestheconcurrencyinthesystembyblockingtheprogressof schedulableobjects,andcausesthewell-knownproblemsofdeadlock,starvation, priorityinversionetc.

Thishasledtothedevelopmentofnon-blockingapproaches.Anapproach isnon-blockingifthefailureorsuspensionofanyschedulableobjectscannot causethefailureorsuspensionofanyotherschedulableobject[172].Nonblockingalgorithmsareusuallyclassifiedaseither lock-free or wait-free.Froma multiprocessorreal-timeperspective,thefollowingtypicallyapply[79].

•Lock-free–accesstothesharedobjectisimmediatebut,followingcompletion ofthedesiredoperation,theschedulable objectmustbeabletodetectandresolve anycontentionthatmayhaveoccurred.Oftenresolvingtheconflictrequires retryingtheoperation.Whencontentionoccurs,someschedulableobjectis guaranteedtomakeprogress.However,itisnotdefinedwhichone.Software transactionalmemoryisanexamplewherealock-freeapproachispossible. Boundingtheretriesisamajorchallengeforthereal-timealgorithmdesigner.

•Wait-free–accesstothesharedresourceisimmediateandisguaranteed tocompletesuccessfullywithinfinitetime.Typically,specificwait-freedata structuresarehighlyspecializedandaredifficulttodesignandprovecorrect. Examplesinclude,await-freequeueorawait-freestack.Genericwait-freereadwriteaccesstoasinglesharedobjectcanbesupported(e.g.usingSimpson’s algorithm[379]forasinglereaderandsinglewriter)butatthecostofreplicating thedata.Hence,datareadmaybestaleifawriteriscurrentlyupdatingit.

QuotingfromBrandenburgetal.[79]whogivethefollowingconclusionsfrom anin-depthstudyonreal-timesynchronizationonmultiprocessors:

•whenimplementingshareddataobjects,non-blockingalgorithmsaregenerally preferableforsmall,simpleobjects,andwait-freeorspin-based(locking) implementationsaregenerallypreferableforlargeorcomplexobjects;

•Wait-freealgorithmsarepreferabletolock-freealgorithms;

•withfrequentlyoccurringlongordeeply-nestedcriticalsections,schedulability islikelytobepoor(underanyscheme);

•Suspension-basedlockingshouldbeavoidedforglobalresourcesinpartitioned systems3 ;

•usingcurrentanalyticaltechniques,suspension-basedlockingisneverpreferable (onthebasisofschedulabilityortardiness)tospin-basedlocking;

3 Thisisaparaphrasefromtheoriginalwhichfocusedonaparticularpartitioningscheme.

•ifsuchtechniquescanbeimproved,thentheuseofsuspension-basedlocking willmostlikelynotleadtoappreciablybetterschedulabilityortardinessthan spinningunlessasystem(initsentirety)spendsatleast20%ofitstimeincritical sections(somethingwefindhighlyunlikelytobethecaseinpractice).

Ofcourse,thechoiceofwhatapproachtoadoptisconstrainedbythedata structuresneeded.Thereisnosimplegeneralapproachtotakingaparticulardata structureandproducinganon-blockingaccessprotocol.4 Furthermore,itshouldbe emphasizedthatthisstudyexcludedexternaldeviceswithlongaccesstimesfor whichsuspension-basedlockingisessential.

1.3OperatingSystemSupport

Althoughmultiprocessorsarebecomingprevalent,therearenoagreedstandards onhowbesttoaddressreal-timedemands.Forexample,theRTEMoperating systemdoesnotdynamicallymovethreadsbetweenCPU.Insteaditprovides mechanismswherebytheycanbestaticallyallocatedatlinktime.Incontrast, QNX’sNutrino[311]distinguishesbetween“hardthreadaffinity”and“softthread affinity”.Theformerprovidesamechanismwherebytheprogrammercanrequire thatathreadbeconstrainedtoexecute onlyonasetofprocessors(indicatedbya bitmask).Withthelatter,thekerneldispatchesthethreadtothesameprocessoron whichitlastexecuted(inordertocutdownonpreemptioncosts).Otheroperating systemsprovidesimilarfacilities.Forexample,IBM’sAIXallowsakernelthread tobeboundtoaparticularprocessor.5 Inaddition,AIXenablesthesetofprocessors (andtheamountofmemory)allocatedtothepartitionexecutinganapplicationto bechangeddynamically.

Manymultiprocessorsystemsallowinterruptstobetargetedatparticularprocessors.Forexample,theARMCorexA9-MPCoresupportstheArmGenericInterrupt Controller.6 ThisallowsatargetlistofCPUstobespecifiedforeachhardware interrupt.Softwaregeneratedinterruptscanalsobesenttothelistorsetuptobe deliveredtoallbuttherequestingCPUoronlytherequestingCPU.Ofcourse, whethertheOperatingSystemallowsthistargetingisanothermatter.

Safetycriticalsystemsoftwaremustbepredictableenoughthatmostfailures canbedetectedanalyticallyorthroughsystematictesting.Thisrulesoutthenondeterminismimplicitinflexibleschedulingacrossmultipleprocessors.Itmayeven ruleoutinteractionsamongthreadsondifferentprocessors.Currentlythereislimiteduseofgeneralmultiprocessorsystemsinsafetycriticalsystems.Traditionally,

4 Thiscanbecontrastedtosimplytakingthecurrentaccessprotocolandsurroundingitcallstoan appropriatelocktosupportablocking-basedaccessprotocol.

5 See http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.basetechref/doc/ basetrf1/bindprocessor.htm

6 See http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0375a/Cegbfjhf.html

wheremultiprocessorsarerequiredtheyareusedinadistributedprocessingmode: withboardsorboxesinterconnectedbycommunicationsbusses,andbandwidth allocation,andthetimingofmessagetransfersetccarefullymanaged.This“hard” partitioningsimplifiescertificationandtestingsinceoneapplicationcannotaffect anotherexceptthroughwell-definedinterfaces.

However,thereisevidencethatfuturesafety-criticalsystemswilluseSMP. Forexample,theLynxSecureSeparationKernel(Version5.0)hasrecentlybeen announced.Thefollowingistakenfromtheirwebsite7 :

•Optimalsecurityandsafety–theonlyoperatingsystemtosupportCCEAL-7 andDO-178BlevelA.

•Realtime–time-spacepartitionedreal-timeoperatingsystemforsuperior determinismandperformance.

•Highlyscalable–supportsSymmetric MultiProcessing(SMP)and64-bitaddressingforhigh-endscalability.

ThisworkhasbeenundertakenbyIntelandLynuxWorkstodemonstratetheMILS (MultipleIndependentLevelsofSecurity)architecture.8

Intheremainderofthissection,webrieflyreviewtheworkthathasbeen performedbythePOSIXandLinuxcommunities.WethenconsiderSolarisasan exampleofthesupportprovidedbyavendor-specificOS.

1.3.1POSIX

POSIX.1definesa“SchedulingAllocationDomain”asthesetofprocessorson whichanindividualthreadcanbescheduledatanygiventime.POSIXstates that[286]:

•“Forapplicationthreadswithschedulingallocationdomainsofsizeequaltoone, theschedulingrulesdefinedforSCHED FIFOandSCHED RRshallbeused.”

•“Forapplicationthreadswithschedulingallocationdomainsofsizegreaterthan one,therulesdefinedforSCHED FIFO,SCHED RR,andSCHED SPORADIC shallbeusedinanimplementation-definedmanner.”

•“Thechoiceofschedulingallocationdomainsizeandthelevelofapplication controloverschedulingallocationdomainsisimplementation-defined.Conformingimplementationsmaychangethesizeofschedulingallocationdomainsand thebindingofthreadstoschedulingallocationdomainsatanytime.”

Withthisapproach,itisonlypossibletowritestrictlyconformingapplications withreal-timeschedulingrequirementsforsingle-processorsystems.IfanSMP platformisused,thereisnoportablewaytospecifyapartitioningbetweenthreads andprocessors.

7 http://www.lynuxworks.com/rtos/secure-rtos-kernel.php.

8 See http://www.intel.com/technology/itj/2006/v10i3/5-communications/6-safety-critical.htm.

AdditionalAPIshavebeenproposed[272]butcurrentlythesehavenotbeenstandardized.Theapproachhasbeentosettheinitialallocationdomainofathreadas partofitsthread-creationattributes.Theproposalisonlyindraftandsonodecision hasbeentakenonwhethertosupportdynamicallychangingtheallocationdomain.

1.3.2Linux

SinceKernelversion2.5.8,LinuxhasprovidedsupportforSMPsystems[136]. PartitioningofuserprocessesandthreadsisobtainedviathenotionofCPUaffinity. EachprocessinthesystemcanhaveitsCPUaffinitysetaccordingtoaCPUaffinity mask[251].Aprocess’sCPUaffinitymaskdeterminesthesetofCPUsonwhichits threadareeligibletorun.

#include<sched.h>

intsched_setaffinity(pid_tpid, unsignedintcpusetsize,cpu_set_t *mask);

intsched_getaffinity(pid_tpid, unsignedintcpusetsize,cpu_set_t *mask);

voidCPU_CLR(intcpu,cpu_set_t *set);

intCPU_ISSET(intcpu,cpu_set_t *set);

voidCPU_SET(intcpu,cpu_set_t *set);

voidCPU_ZERO(cpu_set_t *set);

ACPUaffinitymaskisrepresentedbythe cpu set t structure,a“CPU set”,pointedtobythemask.FourmacrosareprovidedtomanipulateCPUsets.

CPU ZERO clearsaset. CPU SET and CPU CLR respectivelyaddandremovea givenCPUfromaset. CPU ISSET teststoseeifaCPUispartoftheset.The firstavailableCPUonthesystemcorrespondstoacpuvalueof0,thenextCPU correspondstoacpuvalueof1,andsoon.Aconstant CPU SETSIZE(1024) specifiesavalueonegreaterthanthemaximumCPUnumberthatcanbestoredina CPUset.

sched setaffinity setstheCPUaffinitymaskoftheprocesswhoseIDis pidtothevaluespecifiedbymask.Iftheprocessspecifiedbypidisnotcurrently runningononeoftheCPUsspecifiedinmask,thenthatprocessismigratedtoone oftheCPUsspecifiedinmask[251].

sched getaffinity allowsthecurrentmasktobeobtained.Theaffinity maskisactuallyaper-threadattributethatcanbeadjustedindependentlyforeach ofthethreadsinathreadgroup.

Linuxalsoallowscertaininterruptstobetargetedtospecificprocessors(orgroups ofprocessors).ThisisknownasSMPIRQaffinity.SMPIRQaffinityiscontrolled bymanipulatingfilesinthe/proc/irq/directory.

Aswellasbeingabletocontroltheaffinityofathreadfromwithintheprogram, Linuxallowsthetotalsetofprocessors(itscpuset)allocatedtoaprocesstobe changeddynamically.Hence,themasksgivento sched setaffinity() must bemoderatedbythekerneltoreflectthoseprocessorsthathavebeenallocatedto theprocess.Cpusetsareintendedtoprovidemanagementsupportforlargesystems. Thereal-timeschedulerofthePREEMPT RTpatchsetusescpusetstocreate a rootdomain.ThisisasubsetofCPUsthatdoesnotoverlapwithanyother subset.Thescheduleradoptsanactivepush-pullstrategyforbalancingreal-time tasks(taskswhopriorityrangefrom0to(MAX RT PRIO-1))acrossCPUs.Each CPUhasitsownrunqueue.Theschedulerdecides[169]:

1.Wheretoplaceataskonwakeup.

2.Whatactiontotakeifalower-prioritytaskisplacedonarunqueuerunninga taskofhigherpriority.

3.Whatactiontotakeifalow-prioritytaskispreemtedbythewake-upofahigherprioritytask.

4.Whatactiontotakewhenatasklowersitspriorityandtherebycausesa previouslylower-prioritytasktohavethehigherpriority.

Essentially,a push operationisinitiatedincases2and3above.Thepush algorithmconsidersalltherunqueueswithinitsrootdomaintofindonethathas alowerprioritytask(thanthetaskbeingpushed)attheheadofitsrunqueue.The tasktobepushedthenpreemptsthelowerprioritytask.

A pull operationisperformedforcase4above.Whenevertheschedulerisabout tochooseataskfromitsrunqueuethatislowerinprioritythanthepreviousone, itcheckstoseewhetheritcanpulltasksofhigherpriorityfromotherrunqueues. Ifitcan,atleastonehigherprioritytasksismovedtoitsrunqueueandischosen asthetasktobeexecuted.Onlyreal-timetasksareaffectedbythepushandpull operations.

1.3.3Solaris

TheSolarisoperatingsystemprovidesfacilitiessimilartothoseofLinux,though thedetailsoftheAPI’sandthelow-levelsemanticsdiffer.The processor bind systemcallcanbeusedtobindoneormorethreads(orLightweightProcesses–LWPs–astheyareknownonSolaris)toaparticularprocessor.

#include<sys/types.h>

#include<sys/processor.h>

#include<sys/procset.h>

intprocessor_bind(idtype_tidtype,id_tid, processorid_tprocessorid, processorid_t *obind);

Solarisallowsthreadstobegroupedaccordingtoprocess,“task”,“project”, “processcontract”andzone,asindicatedbythe idtype t,whichinturndictates whatkindof id t isexpected.Thesamesystemcallcanbeusedtoquery existingbindings,ortoclearthem,byusingthespecial processorid values of PBIND QUERY and PBIND NONE respectively.The obind parameterisused toreturnthepreviousbinding,ortheresultofaquery.

ThebindingofthreadstomultipleprocessorsisdonethroughtheSolaris processorsetfacility.ProcessorsetsaresimilartoLinux’sCPUsets,butrather thanbeinghierarchicaltheyformaflat,disjoint,grouping.Threadswillnotrun onprocessorsinaprocessorsetunlessthethread,oritsprocess,areexplicitly boundtothatprocessorset.Programscanberunonaspecificprocessorsetusing the psrset e< set # >< program > command-lineutility.Whenaprocessis boundtoaprocessorsetinthisway,itsthreadsarerestrictedtotheprocessorsin thatset–the processor bind systemcallcanthenbeusedtofurtherrestrict athreadtoasingleprocessorwithinthat.Anunboundprocesscanonlyrunon anunboundprocessor,sotheremustalwaysbeatleastoneunboundprocessor inasystem.The psrset commandisanadministrativetoolforcreatingand configuringprocessorsets,aswellasameanstoexecuteprogramsonaparticular set–thereisacorrespondingprogrammaticAPIforthisaswell.The pset bind systemcallcanthenbeusedwithinaprogramtobindoneormorethreadstoa differentprocessorsettothatoftheprocess.Forexample,youmightgiveallNHRTs adedicatedprocessorsettorunon.

#include<sys/pset.h>

intpset_bind(psetid_tpset,idtype_tidtype, id_tid,psetid_t *opset);

A psetid t isasimpleintegerthatnamesaparticularprocessorset.The specialvalues PS QUERY and PS NONE indicatearequesttoquery,orclear,the currentprocessorsetbinding,respectively.The opset parameterisusedtoreturn thepreviousbinding,ortheresultofaquery.

Processorsaremanagedbythe psradm utility(ortheequivalentprogrammatic API)whichallowsforprocessortobetakenoffline(theywon’texecuteanythreads, butmightfieldI/Odeviceinterrupts),ortobedeclared no-intr (theywillexecute threadsbutwon’tfieldanyI/Odeviceinterrupts).Someinterruptswillalwaysbe handledbyaspecificprocessor,suchasper-cputimerexpirations.

Effectiveprocessorsetmanagementrequiresextremelydetailedknowledge oftheunderlyinghardwareandhowtheoperatingsystemidentifiesindividual “processors”.Onmulti-coresystems,forexample,youneedtounderstandhow coresarenumberedwithinaCPUand/orwithinachip,andwhatresources(e.g. L2cache)mightbesharedbetweenwhichcores.

1.4RequirementsforRTSJVersion1.1

Section 1.2 hassummarizedthemotivationsforprovidingmoreexplicitsupport formultiprocessorsystemsintheRTSJ,alongwiththeconstraintsthatmustbe imposedtomaintainpredictablescheduling.Fromthis,thefollowingrequirements aredistilled.

•Itshallbepossibletolimitthedispatchingofaschedulableobjecttoasingleprocessor–thisisinordertosupportthemotivationsgiveninSects. 1.2.1 and 1.2.2 andtoreflecttheconstraintsgivenforschedulabilityinSect. 1.2.3

ThisisimpossibletoachieveinVersion1.02ofthespecification.Although, the java.lang.Runtime classallowsthenumberofprocessorsavailableto theJavaVirtualMachine(JVM)tobedeterminedbythe availableProcessors() method,itdoesnotallowJavathreadstobepinnedtoprocessors.

•Globalschedulingofschedulableobjectsacrossmorethanoneprocessorshall bepossible–thisisprimarilytoreflecttheconstraintsgivenforschedulability inSect. 1.2.3,andalsobecausethisisthedefaultpositionforRTSJversion1.0.2 implementations.

•Spin-basedqueuelockingprotocolsforsharedobjectsshallnotbeprecluded–thisistoreflectthepredictabilityconstraintsgiveninSect. 1.2.4.

TheJavaintrinsicsynchronizationapproachisbuiltonsuspension-based locking.TheRTSJ,withitssupportfor priorityceilingemulation,potentially allowsano-lockimplementationofJavamonitorsonasingleprocessorbut onlyforconstrainedsynchronizedmethodsandstatements(i.e.onesthatdonot selfsuspend).Implementingnon-lockingJavamonitorsisdifficulttosupportin general.TheRTSJwait-freequeuefacilityprovidesanalternativemechanismfor schedulableobjectstocommunicate.

•TheimpactoftheJava-levelhandlingofexternaleventsshouldbeconstrainable toasubsetoftheavailableprocessors–thisistoreflectthemotivationsgivenin Sect. 1.2.1.

IntheRTSJallexternaleventsareassociatedwith happenings.Whilstitmay notbepossibletoconstrainwherethefirst-levelinterruptcodeexecutes,itshould bepossibletocontrolwheretheJavacodeexecutesthatrespondstotheinterrupt.

ThesupportthattheRTSJprovidesformultiprocessorsystemsisprimarilyconstrainedbythesupportitcanexpectfromtheunderlyingoperatingsystem. Thefollowinghavehadthemostimpactonthelevelofsupportthathasbeen specified.

•Thenotionofprocessor affinity iscommonacrossoperatingsystemsandhas becometheacceptedwaytospecifytheconstraintsonwhichprocessorathread canexecute.

RTSJ1.1directlysupportsaffinities.A processoraffinityset isasetof processorsthatcanbeassociatedwithaJavathreadorRTSJschedulableobject. Theinternalrepresentationofasetofprocessorsinan AffinitySet instance isnotspecified,buttherepresentationthatisusedtocommunicatewiththis classisa BitSet whereeachbitcorrespondstoalogicalprocessorID.The relationshipbetweenlogicalandphysicalprocessorsisimplementationdefined.

Insomesense,processoraffinitiescanbeviewedasadditionalreleaseor schedulingparameters.However,toaddthemtotheparameterclassesrequires thesupporttobedistributedthroughoutthespecificationwithaproliferation ofnewconstructormethods.Toavoidthis,supportisgroupedtogetherwithin the ProcessorAffinitySet class.Theclassalsoallowstheadditionof processoraffinitysupporttoJavathreadswithoutmodifyingthethreadobject’s visibleAPI.

•Therangeofprocessorsonwhichglobalschedulingispossibleisdictated bytheoperatingsystem.ForSMParchitectures,globalschedulingacrossall theprocessorsinthesystemistypicallysupported.However,anapplication andanoperatorcanconstrainthreadsandprocessestoexecuteonlywithina subsetoftheprocessors.Asthenumberofprocessorsincrease,thescalabilityof globalschedulingiscalledintoquestion.Hence,forNUMAarchitecturessome partitioningoftheprocessorsislikelytoperformedbytheOS.Hence,global schedulingacrossallprocessorswillnotbepossibleinthesesystems.

TheRTSJsupportsanarrayof predefinedaffinitysets.Theseare implementation-defined.Theycanbeusedeithertoreflectthescheduling arrangementoftheunderlyingOSortheycanbeusedbythesystemdesigner toimposedefaultsfor,say,Javathreads,non-heapreal-timeschedulableobjects etc.Aprogramisonlyallowedtodynamicallycreatenewaffinitysetswith cardinalityofone.Thisrestrictionreflectstheconcernthatnotalloperating systemswillsupportmultiprocessoraffinitysets.

•ManyOSsgivesystemoperatorscommand-leveldynamiccontrolovertheset ofprocessorsallocatedtoaprocesses.Consequently,thereal-timeJVMhasno controloverwhetherprocessorsaredynamicallyaddedorremovedfromitsOS process.

PredictabilityisaprimeconcernoftheRTSJ.Clearly,dynamicchangestothe allocatedprocessorswillhaveadramatic,andpossiblycatastrophic,effectonthe abilityoftheprogramtomeettimingrequirements.Hence,theRTSJassumes thattheprocessorsetallocatedtotheRTSJprocessdoesnotchangeduringits execution.Ifasystemiscapableofsuchmanipulationitshouldnotexerciseiton RTSJprocesses.

InordertomaketheRTSJ1.1fullydefinedformultiprocessorsystems,the followingissuesneededtobeaddressed.

1.Thedispatchingmodel–version1.02ofthespecificationhasaconceptualmodel whichassumedasinglerunqueueperprioritylevel.

2.Theprocessorallocationmodel–version1.02ofthespecificationprovidesno mechanismstosupportprocessoraffinity.

3.Thesynchronizationmodel–version1.02ofthespecificationdoesnotprovideanydiscussionoftheintendeduseofitsmonitorcontrolpoliciesin multiprocessorsystems.

4.Thecostenforcementmodel–version1.02ofthespecificationdoesnotconsider thefactthatprocessinggroupscancontainschedulingobjectswhichmightbe simultaneouslyexecuting.

5.Theaffinityofexternalevents(happenings)–version1.02ofthespecification providesnomechanismtotiehappeningshandlerstoparticularprocessors. Theremainderofthissectionconsiderseachoftheaboveissuesinturn. AnappendixgivestheassociatedAPIs.

1.5.1TheDispatchingModel

TheRTSJdispatchingmodelspecifiesitsdispatchingrulesforthedefaultpriority scheduler.Here,therulesaremodifiedtoaddressmultiprocessorconcerns.

1.Aschedulableobjectcanbecomearunningschedulableobjectonlyifitisready andtheexecutionresourcesrequiredbythatschedulableobjectareavailable.

2.Processorsareallocatedtoschedulableobjectsbasedoneachschedulable object’sactivepriorityandtheirassociatedaffinitysets.

3.Schedulableobjectdispatchingistheprocessbywhichonereadyschedulable objectisselectedforexecutiononaprocessor.Thisselectionisdoneat certainpointsduringtheexecutionofaschedulableobjectcalled schedulable objectdispatchingpoints.Aschedulableobjectreachesa schedulableobject dispatchingpoint wheneveritbecomesblocked,whenitterminates,orwhena higherpriorityschedulableobjectbecomesreadyforexecutiononitsprocessor.

4.Theschedulableobjectdispatchingpolicyisspecifiedintermsof readyqueues andschedulableobjectstates.Thereadyqueuesarepurelyconceptual;thereis norequirementthatsuchlistsphysicallyexistinanimplementation.

5.Areadyqueueisanorderedlistofreadyschedulableobjects.Thefirstposition inaqueueiscalledtheheadofthequeue,andthelastpositioniscalledthetailof thequeue.Aschedulableobjectisreadyifitisinareadyqueue,orifitisrunning. Eachprocessorhasonereadyqueuefor eachpriorityvalue.Atanyinstant,each readyqueueofaprocessorcontainsexactlythesetofschedulableobjectsofthat prioritythatarereadyforexecutiononthatprocessor,butarenotrunningonany processor;thatis,thoseschedulableobjectsthatareready,arenotrunningonany processor,andcanbeexecutedusingthatprocessor.Aschedulableobjectcanbe onthereadyqueuesofmorethanoneprocessor.

6.Eachprocessorhasonerunningschedulableobject,whichistheschedulable objectcurrentlybeingexecutedbythatprocessor.Wheneveraschedulableobject runningonaprocessorreachesaschedulableobjectdispatchingpoint,anew schedulableobjectisselectedtorunonthatprocessor.Theschedulableobject selectedistheoneattheheadofthehighestprioritynonemptyreadyqueuefor thatprocessor;thisschedulableobjectisthenremovedfromallreadyqueuesto whichitbelongs.

Inamultiprocessorsystem,aschedulableobjectcanbeonthereadyqueuesofmore thanoneprocessor.Attheextreme,ifseveralprocessorssharethesamesetofready schedulableobjects,thecontentsoftheirreadyqueuesareidentical,andsotheycan beviewedassharingonereadyqueue,andcanbeimplementedthatway.Thus,the dispatchingmodelcoversmultiprocessorswheredispatchingisimplementedusing asinglereadyqueue,aswellasthosewithseparatedispatchingdomains.

1.5.2TheProcessorAllocationModel

Therequirementisforaminimuminterfacethatallowsthepinningofaschedulable objecttooneormoreprocessors.ThechallengeistodefinetheAPIsothatitallows arangeofoperatingsystemfacilitiestobesupported.Theminimumfunctionality isfortheoperatingsystemtoallowthereal-timeJVMtodeterminehowmany processorsareavailablefortheexecutionoftheJavaapplication.

Thenumberofprocessorsthatthereal-timeJVMisawareofisrepresentedbya BitSet thatisreturnedbythestaticmethod getAvailableProcessors() inthe ProcessorAffinitySet class.Forexample,ina64processorsystem, thereal-timeJVMmaybeawareofall64oronlyasubsetofthose.Ofthese processors,thereal-timeJVMwillknowwhichprocessorshavebeenallocated toit(eitherlogicalprocessorsorphysicalprocessorsdependingontheOperating System).Eachoftheavailableprocessorsissettooneinthebitset.Hence,the cardinalityofthebitsetrepresentsthenumberofprocessorsthatthereal-timeJVM thinksarecurrentlyavailabletoit.Thelengthofthebitsetisthetotalnumberof processorstheJMisawareof.

Anaffinitysetisasetofprocessorswhichcanbeassociatedwithathread(be itaJavathreadorareal-timethread),anasynchronouseventhandlerorprocessing groupparametersinstance.Forinstancesofthreadandasynchronouseventhandlers, theassociatedaffinitysetbindsthethreadorasynchronouseventhandlertotheset ofprocessors.

Theprocessormembershipofanaffinitysetisimmutable.Theprocessor affinityofinstancesof Thread (includingreal-timethreadsandno-heapthreads) andboundasynchronouseventhandlerscanbechangedbystaticmethodsin ProcessorAffinitySet class.Thechangeinaffinityhasanimpactonthe schedulingofthethreadnolaterthanthenextdispatchingpoint.

Theprocessoraffinityofun-boundasynchronouseventhandlersisfixedtoa defaultvalue,asreturnedbythe getHeapSoDefault and getNoHeapSoDefault methods.

Anaffinitysetfactoryonlygeneratesusable AffinitySet instances;i.e., affinitysetsthatcanbeusedwith set(ProcessorAffinitySet,BoundAsyncEventHandler), set(ProcessorAffinitySet,Thread),and set(ProcessorAffinitySet,ProcessingGroupParameters).The factorycannotcreateanaffinitysetwithmorethanoneprocessormember,but suchaffinitysetsaresupported.TheymaybeinternallycreatedbytheRTSJ runtime,probablyatstartuptime.Thesetofaffinitysetscreatedatstartup isvisiblethroughthe getPredefinedSets(ProcessorAffinitySet[]) method.

Theaffinitysetfactorymaybeusedtocreateaffinitysetswithasingleprocessor memberatanytime,thoughthisoperationonlysupportsprocessormembersthatare validastheprocessoraffinityforathread(atthetimeoftheaffinityset’screation.)

Inmanycases,theinitialaffinitysetofanentityisdeterminedbythatofits creator,buttherearetimeswhenthisisnotpossible:

•AJavathreadcreatedbyaschedulableobjectwillhavetheaffinitysetreturned by getJavaThreadDefaultAffinity.

•AschedulableobjectcreatedbyaJavathreadwillhavetheaffinitysetreturnedby getHeapSoDefaultAffinity,or getNoHeapSoDefaultAffinity, dependingonwhetherornotitusestheheap.

•Anunboundasynchronouseventhandlerwillhavetheaffinitysetreturnedby getHeapSoDefaultAffinity,or getNoHeapSoDefaultAffinity, dependingonwhetherornotitusestheheap.

EveryJavathread,schedulableobjectandprocessinggroupparametersinstance isassociatedwithaprocessoraffinitysetinstance,eitherexplicitlyassigned, inherited,ordefaulted.

Anappendixsummarizesthe ProcessorAffinitySet classAPI.

1.5.3TheSynchronizationModel

RTSJVersion1.1doesnotprescribeaparticularimplementationapproachfor supportingcommunicationbetweenthreads/schedulableobjectsrunningonseparate processors.AsmentionedinSect. 1.2.4,thestateoftheartisstillimmatureinthis areaand,consequently,itwouldbeprematuretoattempttoprovidestandardized support.However,itisclearlyanimportantarea.Inthissection,we,therefore, summarizetheavailableoptions.

1.5.3.1UsingtheRTSJMonitorControlPolicies

Bothpriorityinheritanceandpriorityceilingemulation(PCE)protocolsareappropriateforSMPsystems,althoughthealgorithmusedforsettingofceilingpriority valuesmaychange[312].

Toobtainthebestschedulability,theapproachadvocatedintheliterature,when appliedtoJava,requiresthatsynchronizedmethodsandstatements(thatcanbe calledfromthreads/schedulableobjectsrunningonmorethanoneprocessor)donot suspendholdingthelock;furthermore,nestedsynchronizedcallsareprohibited. Iftheseconstraintshold,thenaformofpriorityceilingemulationcanbeused. Theceilingofthesharedobjectissettobethehighestinthesystem,sothatthe codeeffectivelyexecutesnon-preemptively.Theaccessprotocolrequiresacalling thread/schedulableobjecttonon-preemptivelyspinonaFIFO(orpriority-ordered) queuewhenthelockisunavailable.Wherelocksareonlyaccessedlocally(ifsome formofpartitioningisused),thenormalRTSJrulesforsettingceilingapply,and priorityinheritancecanalsobeused.However,iftheprogrammerfailstoclassify thesharedobjectscorrectly,theblockingthatoccurswhenathreadtriestoaccessa already-lockedobjectmaybecomeunbounded.

Fornestedlocks,thepossibilityofdeadlockisreintroduced inmultiprocessor systems,evenwithpriorityceilingemulation.Consequently,theprogrammermust adoptastrategyforpreventingitfromoccurring.Onesuchapproachistouse theFlexibleMultiprocessorLockingProtocol(FMLP)[60].ApplyingtheFMLP approachtoanRTSJprogramrequirestheprogrammerto:

•Partitionthesharedobjectsintothosewith short and long accessmethods–short accessesshouldnotselfsuspendforanyreason,whilelongaccessesmayself suspend;ifanymethodinanobjectselfsuspendsthentheobjectisalong-access object;

•Short-accessobjectsareaccessedviaqueue-basedspin-locksasdescribedabove;

•Long-accessobjectsareaccessedviasuspension-basedpriorityinheritancelocks (thedefaultRTSJpolicy);

•Nestedaccessesbetweensharedobjectsaregroupedtogetherinto sharedresources –noshort-accesssharedobjectisallowedtoaccessalong-accessshared object;

•Foreachresource,asinglelockisdefined(attheapplicationlevel)–thislock mustbeacquiredbytheapplicationbeforeanyoftheresourceobjectsare accessed;forshortresourcesthisisaspin-basedlock,forlongresourcesthis isapriorityinheritancelock.

Withtheaboveapproach,theresourcelockisusedtoguaranteethedeadlock freedomproperty(itisadeadlock-preventionmechanism).Notethatblockingonly occursonaccesstotheresourcelock.Theseparationoftheresourcesbetweenthose thatareshortandlongallowsfastaccessforthecommonsimplecase.

Notealsothatshortsharedobjectaccessesshouldnotperformanyoperations thatmightcauseittoblockwaitingforthegarbagecollector.

1.5.3.2UsingtheRTSJWait-FreeQueues

TheRTSJgoestogreatlengthtosupportno-heapreal-timethreadsandtoensure thatgarbagecollectiondelayscannotimpactontimecriticalcode.Partofthis supportpackageistheprovisionofno-waitreadandwritequeues.Itisimportantto stressthatthismotivationisslightlydifferentfromtheusualmotivationfor“waitfree”queuesgiveninthereal-timeliterature(seeSect. 1.2.4),wheretheconcernis mainlyforconcurrentaccess.

IntheRTSJ,the WaitFreeReadQueue classisintendedforsingle-reader multiple-writercommunication.Only thereadaccessiswait-free.Ifanapplicationwantstohavemultiplereaders,ithastosupplyitsownsynchronization protocolbetweenthereaderstoensureonlyoneofthemattemptsaccessatany pointintime.Writersarenotwait-free.Areaderisgenerallyaninstanceof NoHeapRealtimeThread,andthewritersaregenerallyregularJavathreads orheap-usingschedulableobjects.Communicationisthroughaboundedbufferof objectsthatismanagedfirst-in-first-out.The write methodappendsanewelement ontothequeue.Itissynchronized,andblockswhenthequeueisfull.Itmaybe calledbymorethanonewriter,inwhichcase,thedifferentcallerswillwriteto differentelementsofthequeue.Thereadmethodremovestheoldestelementfrom thequeue.Itisnotsynchronizedanddoesnotblock;itwillreturnnullwhenthe queueisempty.

Acorrespondingwait-freewritequeuethatisnon-blockingforproducersis alsoprovided.The WaitFreeWriteQueue classisintendedforsingle-writer multiple-readercommunication.Awriterisgenerallyaninstanceof NoHeapRealtimeThread,andthereadersaregenerallyregularJavathreadsorheap-using schedulableobjects.

Onamultiprocessorsystems,althoughthewriteendofareadqueue(andthe readendofawritequeue)aresynchronized,theyareshort(usingthedefinition givenabove).However,theyblockwhenthequeueisfull/empty.

Insummary,theRTSJwait-freequeuesareappropriatefortheirintendedusein amultiprocessorenvironment.However,theyarenotintendedtosolvethegeneral problemofnon-blockingcommunication.

1.5.3.3Usingthe java.util.concurrent.atomic Package

The java.utils.concurrent.atomic package9 providesasetofclasses thatsupportlock-free,thread-safeprogrammingonsinglevariablessuchasintegers, booleans,longsandobjectreferences.Atomicvariablearealso,bydefinition, volatileandhavethesamememorysemantic[172].

9 http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/atomic/package-summary. html

Thespecificationsofthemethodsintherelatedclassesenableimplementations toemployefficientmachine-levelatomicinstructions(whereavailable,suchas compareandswapinstructions).

TheJSR282expertgroupanticipatesthat,asmoreexperienceisaccrued withmultiprocessorreal-timeJavaimplementations,real-timeconcurrencyutilities (using java.util.concurrent.atomic package)willbecomeavailable. Forexample,Javaversionsofreal-timewait-freealgorithmssuchasSimpson’s algorithm[379].

1.5.4TheCostEnforcementModel

TheRTSJmanagestheCPUtimeallocatedtoaschedulableobjectviatwo complementarymechanisms.Thefirstisviathe cost parametercomponentofthe ReleaseParameter class,whichessentiallyrepresentstheworst-caseexecution timeofaschedulableobject.Inversion1.02oftheRTSJtherewasanoptionalcost enforcementmodelthat,ifsupported,requiredaschedulableobjecttoconsumeno morethanthisvalueforeachofitsreleases.Inversion1.1,themodelhasbeen extendedtoalsoprovideasofterapproachwheretheapplicationissimplyinformed ifacostoverrunhasoccurred.Itisalsonowmandatorytoprovidemechanismsto measuretheexecution-timeofaschedulableobject(albeit,withinsomegranularity appropriatefortheunderlyingplatform).

InanSMPsystems(assumingtheprocessorsexecuteatapproximatelythesame speed),theseapproacheseasilyscale fromthesingleprocessormodel(because aschedulableobjectcanonlybeexecutingononeprocessoratatime).Clearly, inaheterogenousarchitecturewhereprocessorsmaydifferinspeed,settingan appropriatevaluefortheexecutiontimeisproblematic.Thisissueisbeyondthe scopeofthischapter.

Thesecond,moreproblematic,mechanismisthatprovidedby ProcessingGroupParameters, 10 whichallowsagroupofschedulableobjectstobeallocatedautilization.Whilstconceptually,thiscouldbeappliedtomultiplethreads fromthesamegroupexecutinginparallelwithglobalscheduling,itisnot clearthatthegeneralmodelshouldbeappliedtoapartitionedsystem.Indeed, theimplementationchallengeofdetectingbudgetoverrunmaymakethewhole approachuntenable.Instead,itisnecessary toplaceaconstraintthatallschedulable objectsallocatedtoaprocessinggroupmustbeallocatedtothesameprocessor.

Theapproachadoptedinversion1.1oftheRTSJisthatreal-timethreads andboundasynchronouseventhandlersthathaveprocessinggroupparameters aremembersofthatprocessinggroup,andtheirprocessoraffinityisgoverned bytheintersectionoftheprocessinggroup’saffinityandtheschedulableobject’s

affinity.Theaffinitysetofaprocessinggroupmusthaveexactlyoneprocessor.The intersectionofanon-defaultPGaffinitysetwiththeschedulableobject’saffinityset mustcontainatmostoneentry.Iftheintersectionisempty,theaffinityissettothe defaultset.

Themanipulationsofaffinitiesforprocessinggroupsisprovidedbystaticmethodsinthe ProcessorAffinitySet class.Thisclassalsocontrolsthedefault affinityusedwhenaprocessinggroupiscreated.Thatvalueisthesetofallavailable processors.(Whichpermitseachmember oftheprocessinggrouptousetheaffinity setitwoulduseifitwereinnoprocessinggroup.)Theprocessoraffinityoftheprocessinggroupcansubsequentlybealteredwiththe set(ProcessorAffinitySet,ProcessingGroupParameters) method.

1.5.5AffinityandHappenings

Inversion1.1oftheRTSJ,themodelforinterfacingwiththeexternalenvironment hasbeensignificantlyenhanced(seeChap.6).Inparticular,theRTSJnotionof happenings hasbeenextendedsotheycanbehandledatvariouslevels.

Fromanaffinityperspective,thefollowingdefinitionsandpointsapply:

•Afirst-levelinterrupthandleristhecodethattheplatformexecutesinresponse tothehardwareinterrupts.Afirstlevelinterruptisassumedtobeexecutedatan executioneligibility(priority)andhasanaffinitybothdictatedbytheunderlying platform(whichmaybecontrollableattheplatformlevel).

•Onastand-aloneJVM,ahandlerisalsoneeded.ThisisthecodethattheJVM executesasaresultofbeingnotifiedbythefirst-levelinterrupthandlerthatthe interruptistargetedattheRTSJapplication.WhentheJVMishostedonan OperatingSystem,theequivalentlevelistheJVMcodethatexecutesinresponse toasignalbeingreceived.Thiscodecan nowbeassociatedwithaschedulable objectandcanhaveapplication-definedaffinityandexecutioneligibility.

•Ifappropriate,theJava-levelhandlercanfindoneormoreassociatedasynchronouseventsandfirethem.ThisthenreleasestheassociatedRTSJasynchronouseventhandlers.Thesecanhaveapplication-definedaffinityand executioneligibility.

1.6Conclusions

Asthecomplexityofreal-timeandembeddedsystemscontinuestogrow,there islittledoubtthattheywillinfuturerelyon multiprocessor/multicoreplatforms. Aswithallresources,itisnecessarytoallowthereal-timeprogrammertohave theultimatecontrolovertheiruse.Hence,facilitiesmustbemadeavailableatthe