3.1 Aktivt objekt
Et aktivt objekt er et designmønster, der adskiller udførelsestråden for en metode fra den tråd, den blev kaldt i. Formålet med dette mønster er at tilvejebringe parallel eksekvering ved brug af asynkrone metodekald og en planlægningsprogrammer for anmodningsbehandling.
Forenklet version:
Klassisk variant:
Denne skabelon har seks elementer:
- Et proxyobjekt, der giver en grænseflade til klientens offentlige metoder.
- En grænseflade, der definerer adgangsmetoder for det aktive objekt.
- Liste over indgående anmodninger fra kunder.
- En planlægger, der bestemmer rækkefølgen, som forespørgsler skal udføres i.
- Implementering af aktive objektmetoder.
- En tilbagekaldsprocedure eller en variabel for klienten for at modtage et resultat.
3.2 lås
Låsemønsteret er en synkroniseringsmekanisme, der giver mulighed for eksklusiv adgang til en delt ressource mellem flere tråde. Låse er en måde at håndhæve politik for samtidighedskontrol.
Grundlæggende bruges en blød lås med den antagelse, at hver tråd forsøger at "erhverve låsen", før den får adgang til den tilsvarende delte ressource.
Nogle systemer har dog en obligatorisk låsemekanisme, hvorved et uautoriseret adgangsforsøg til en låst ressource vil blive afbrudt ved at kaste en undtagelse på den tråd, der forsøgte at få adgang.
En semafor er den enkleste type lås. Med hensyn til dataadgang skelnes der ikke mellem adgangstilstande: delt (skrivebeskyttet) eller eksklusiv (læse-skrive). I delt tilstand kan flere tråde anmode om en lås for at få adgang til data i skrivebeskyttet tilstand. Den eksklusive adgangstilstand bruges også i opdaterings- og sletningsalgoritmerne.
Typerne af låse er kendetegnet ved strategien for at blokere fortsættelsen af udførelsen af tråden. I de fleste implementeringer forhindrer en anmodning om en lås tråden i at fortsætte med at udføre, indtil den låste ressource er tilgængelig.
En spinlock er en lås, der venter i en løkke, indtil der gives adgang. En sådan lås er meget effektiv, hvis en tråd venter på en lås i et lille stykke tid, hvorved man undgår overdreven omlægning af tråde. Omkostningerne ved at vente på adgang vil være betydelige, hvis en af trådene holder låsen i lang tid.
For effektivt at implementere låsemekanismen kræves støtte på hardwareniveau. Hardwaresupport kan implementeres som en eller flere atomoperationer såsom "test-and-set", "hent-and-add" eller "compare-and-swap". Sådanne instruktioner giver dig mulighed for uden afbrydelse at kontrollere, at låsen er fri, og i så fald anskaffe låsen.
3.3 Monitor
Monitormønsteret er en procesinteraktion og synkroniseringsmekanisme på højt niveau, der giver adgang til delte ressourcer. En tilgang til at synkronisere to eller flere computeropgaver ved hjælp af en fælles ressource, normalt hardware eller et sæt variable.
I monitor-baseret multitasking indsætter compileren eller fortolkeren transparent låse-oplåsningskode i passende formaterede rutiner, transparent for programmøren, hvilket sparer programmøren fra eksplicit at kalde synkroniseringsprimitiver.
Monitoren består af:
- et sæt procedurer, der interagerer med en delt ressource
- mutex
- variabler forbundet med denne ressource
- en invariant, der definerer betingelser for at undgå en racetilstand
Overvågningsproceduren indhenter mutex'en før arbejdet påbegyndes og holder den enten indtil proceduren afsluttes, eller indtil en bestemt tilstand afventes. Hvis hver procedure garanterer, at invarianten er sand, før du frigiver mutexen, så kan ingen opgave erhverve ressourcen i en racetilstand.
Sådan fungerer den synkroniserede operatør i Java med metoderne wait()og notify().
3.4 Dobbelttjek låsning
Dobbelt tjekket låsning er et parallelt designmønster beregnet til at reducere omkostningerne ved at få en lås.
Først kontrolleres blokeringstilstanden uden nogen synkronisering. En tråd forsøger kun at erhverve en lås, hvis resultatet af kontrollen indikerer, at den skal erhverve låsen.
//Double-Checked Locking
public final class Singleton {
private static Singleton instance; //Don't forget volatile modifier
public static Singleton getInstance() {
if (instance == null) { //Read
synchronized (Singleton.class) { //
if (instance == null) { //Read Write
instance = new Singleton(); //
}
}
}
}Hvordan opretter man et singleton-objekt i et trådsikkert miljø?
public static Singleton getInstance() {
if (instance == null)
instance = new Singleton();
}Hvis du opretter et Singleton-objekt fra forskellige tråde, kan der være en situation, hvor flere objekter oprettes på samme tid, og det er uacceptabelt. Derfor er det rimeligt at pakke objektoprettelsen ind i en synkroniseret sætning.
public static Singleton getInstance() {
synchronized (Singleton.class) {
if (instance == null)
instance = new Singleton();
}
}Denne tilgang vil fungere, men den har en lille ulempe. Efter at objektet er oprettet, vil der, hver gang du forsøger at få det i fremtiden, blive udført en kontrol i den synkroniserede blok, hvilket betyder, at den aktuelle tråd og alt, der er forbundet med den, bliver låst. Så denne kode kan optimeres lidt:
public static Singleton getInstance() {
if (instance != null)
return instance;
synchronized (Singleton.class) {
if (instance == null)
instance = new Singleton();
}
}På nogle sprog og/eller på nogle maskiner er det ikke muligt at implementere dette mønster sikkert. Derfor kaldes det nogle gange et anti-mønster. Sådanne funktioner har ført til fremkomsten af "skeder før" strenge rækkefølgeforhold i Java Memory Model og C++ Memory Model.
Det bruges typisk til at reducere omkostningerne ved at implementere doven initialisering i flertrådede programmer, såsom Singleton-designmønsteret. Ved doven initialisering af en variabel udskydes initialisering, indtil værdien af variablen er nødvendig i beregningen.
3.5 Planlægger
Scheduler er et parallelt designmønster, der giver en mekanisme til implementering af en planlægningspolitik, men som er uafhængig af en bestemt politik. Styrer rækkefølgen, som tråde skal udføre sekventiel kode i, ved hjælp af et objekt, der eksplicit specificerer rækkefølgen af ventende tråde.
