Synkronisering (informatikk) - Synchronization (computer science)

I informatikk , synkronisering refererer til en av to forskjellige men beslektede begreper: synkronisering av prosesser , og synkronisering av data . Prosessynkronisering refererer til ideen om at flere prosesser skal slå seg sammen eller håndtrykke på et bestemt tidspunkt for å nå enighet eller forplikte seg til en bestemt handlingsrekkefølge. Datasynkronisering refererer til ideen om å beholde flere kopier av et datasett i sammenheng med hverandre, eller å opprettholde dataintegritet . Prosessynkronisering primitiver brukes ofte for å implementere datasynkronisering.

Behovet for synkronisering

Behovet for synkronisering oppstår ikke bare i flerprosessorsystemer, men for enhver form for samtidige prosesser; selv i enkeltprosessorsystemer. Nedenfor nevnes noen av de viktigste behovene for synkronisering:

Forks and Joins : Når en jobb kommer til et gaffelpunkt, deles den opp i N underjobber som deretter betjenes av n oppgaver. Etter å ha blitt betjent, venter hver underjobb til alle andre underjobber er ferdig behandlet. Deretter blir de slått sammen igjen og forlater systemet. Dermed krever parallell programmering synkronisering ettersom alle parallelle prosesser venter på at flere andre prosesser skal skje.

Produsent-forbruker: I et produsent-forbrukerforhold er forbrukerprosessen avhengig av produsentprosessen til de nødvendige dataene er produsert.

Eksklusive bruksressurser: Når flere prosesser er avhengige av en ressurs og de trenger tilgang til den samtidig, må operativsystemet sikre at bare én prosessor får tilgang til den på et gitt tidspunkt. Dette reduserer samtidigheten.

Tråd eller prosess synkronisering

Image
Figur 1 : Tre prosesser som får tilgang til en delt ressurs ( kritisk seksjon ) samtidig.

Trådsynkronisering er definert som en mekanisme som sikrer at to eller flere samtidige prosesser eller tråder ikke samtidig utfører et bestemt programsegment kjent som kritisk seksjon . Prosessenes tilgang til kritisk seksjon styres ved hjelp av synkroniseringsteknikker. Når en tråd begynner å utføre den kritiske delen (seriell segment av programmet), bør den andre tråden vente til den første tråden er ferdig. Hvis riktige synkroniseringsteknikker ikke brukes, kan det forårsake en løpstilstand der verdiene til variabler kan være uforutsigbare og variere avhengig av tidspunktene for kontekstbrytere for prosessene eller trådene.

Anta for eksempel at det er tre prosesser, nemlig 1, 2 og 3. Alle tre utføres samtidig, og de må dele en felles ressurs (kritisk seksjon) som vist i figur 1. Synkronisering bør brukes her for å unngå konflikter for tilgang til denne delte ressursen. Derfor, når prosess 1 og 2 begge prøver å få tilgang til denne ressursen, bør den bare tildeles en prosess om gangen. Hvis den er tilordnet prosess 1, må den andre prosessen (prosess 2) vente til prosess 1 frigjør ressursen (som vist i figur 2).

Image
Figur 2 : En prosess som får tilgang til en delt ressurs hvis tilgjengelig, basert på noen synkroniseringsteknikk.

Et annet synkroniseringskrav som må vurderes er rekkefølgen der bestemte prosesser eller tråder skal utføres. For eksempel kan man ikke gå ombord på et fly før man kjøper billett. På samme måte kan man ikke sjekke e-postmeldinger før man har validert de riktige legitimasjonene (for eksempel brukernavn og passord). På samme måte vil en minibank ikke tilby noen tjenester før den mottar en riktig PIN -kode.

Annet enn gjensidig eksklusjon, handler synkronisering også om følgende:

  • fastlåst , som oppstår når mange prosesser venter på en delt ressurs (kritisk seksjon) som holdes av en annen prosess. I dette tilfellet fortsetter prosessene å vente og utføres ikke lenger;
  • sult , som oppstår når en prosess venter på å gå inn i den kritiske delen, men andre prosesser monopoliserer den kritiske delen, og den første prosessen blir tvunget til å vente på ubestemt tid;
  • prioritert inversjon , som oppstår når en prosess med høy prioritet er i den kritiske delen, og den blir avbrutt av en prosess med middels prioritet. Dette bruddet på prioriterte regler kan skje under visse omstendigheter og kan føre til alvorlige konsekvenser i sanntidssystemer;
  • opptatt venter , som oppstår når en prosess ofte avstemmer for å avgjøre om den har tilgang til en kritisk seksjon. Denne hyppige avstemningen frarøver behandlingstid fra andre prosesser.

Minimerer synkronisering

En av utfordringene for exascale algoritmedesign er å minimere eller redusere synkronisering. Synkronisering tar mer tid enn beregning, spesielt i distribuert databehandling. Reduksjon av synkronisering vakte oppmerksomhet fra datavitenskapere i flere tiår. Mens det blir et stadig større problem nylig ettersom gapet mellom forbedring av databehandling og latens øker. Eksperimenter har vist at (global) kommunikasjon på grunn av synkronisering på distribuerte datamaskiner tar en dominert andel i en sparsom iterativ løsning. Dette problemet får stadig mer oppmerksomhet etter fremveksten av en ny benchmark -beregning, High Performance Conjugate Gradient (HPCG), for å rangere de 500 beste superdatamaskinene.

Klassiske problemer med synkronisering

Følgende er noen klassiske synkroniseringsproblemer:

Disse problemene brukes til å teste nesten alle nylig foreslåtte synkroniseringsordninger eller primitive.

Maskinvaresynkronisering

Mange systemer gir maskinvarestøtte for kritisk seksjonskode .

En enkelt prosessor eller enkeltprosessor-system kunne deaktivere avbrudd ved å utføre kjørende kode uten Ranganropet , som er meget ineffektivt på flerprosessorsystemer. "Den viktigste evnen vi trenger for å implementere synkronisering i en multiprosessor er et sett med maskinvareprimitiver med evnen til å atomisk lese og endre et minnested. Uten en slik evne vil kostnadene ved å bygge grunnleggende synkroniseringsprimitiver være for høye og vil øke som prosessortallet øker. Det finnes en rekke alternative formuleringer av de grunnleggende maskinvareprimitivene, som alle gir muligheten til atomisk å lese og endre et sted, sammen med en måte å fortelle om lese og skrive ble utført atomisk. Disse maskinvare primitivene er de grunnleggende byggeklossene som brukes til å bygge en rekke synkroniseringsoperasjoner på brukernivå, inkludert ting som låser og barrierer . Generelt forventer arkitekter ikke at brukerne skal bruke de grunnleggende maskinvareprimitivene, men forventer i stedet at primitivene vil brukes av systemprogrammerere til å bygge et synkroniseringsbibliotek, en prosess som ofte er kompleks og vanskelig. " Mange moderne maskinvarer gir spesielle atomare maskinvareinstruksjoner ved enten å teste og angi minneordet eller sammenligne og bytte innhold i to minneord.

Synkroniseringsstrategier i programmeringsspråk

I Java , for å forhindre trådforstyrrelser og feil i minnekonsistens, blir kodeblokker pakket inn i synkroniserte (lock_object) seksjoner. Dette tvinger enhver tråd til å anskaffe nevnte låseobjekt før den kan utføre blokken. Låsen frigjøres automatisk når tråden som ervervet låsen, og deretter utfører blokken, forlater blokken eller går inn i ventetilstand i blokken. Eventuelle variabeloppdateringer, laget av en tråd i en synkronisert blokk, blir synlige for andre tråder når de på samme måte får låsen og utfører blokken.

Java -synkroniserte blokker, i tillegg til å muliggjøre gjensidig eksklusjon og minnekonsistens, aktiverer signalering - dvs. å sende hendelser fra tråder som har fått låsen og kjører kodeblokken til de som venter på låsen i blokken. Dette betyr at Java -synkroniserte seksjoner kombinerer funksjonaliteten til mutexer og hendelser. Slik primitiv er kjent som synkroniseringsmonitor .

Ethvert objekt kan brukes som en lås/skjerm i Java. Det deklarerende objektet er et låseobjekt når hele metoden er merket med synkronisert .

Den .NET Framework har synkroniserings primitiver. "Synkronisering er designet for å være samarbeidende, og krever at hver tråd eller prosess følger synkroniseringsmekanismen før du får tilgang til beskyttede ressurser (kritisk seksjon) for konsekvente resultater." I .NET er låsing, signalering, lette synkroniseringstyper, spinwait og sammenlåste operasjoner noen av mekanismene knyttet til synkronisering.

Implementering av synkronisering

Spinlock

Hovedartikkel: Spinlock

En annen effektiv måte å implementere synkronisering er ved å bruke spinlocks. Før du får tilgang til en delt ressurs eller kodebit, sjekker hver prosessor et flagg. Hvis flagget tilbakestilles, setter prosessoren flagget og fortsetter å utføre tråden. Men hvis flagget er satt (låst), vil trådene fortsette å snurre i en sløyfe og fortsette å sjekke om flagget er satt eller ikke. Men spinlocks er bare effektive hvis flagget tilbakestilles for lavere sykluser, ellers kan det føre til ytelsesproblemer ettersom det kaster bort mange prosessorsykluser som venter.

Barrierer

Hovedartikkel: Barriere (informatikk)

Barrierer er enkle å implementere og gir god respons. De er basert på konseptet med å implementere ventesykluser for å gi synkronisering. Tenk på at tre tråder kjører samtidig, fra barriere 1. Etter tid t når tråd1 barriere 2, men den må fortsatt vente på at tråd 2 og 3 når barriere2, siden den ikke har riktige data. Når alle trådene når barriere 2 starter de alle igjen. Etter tid t når tråd 1 barriere3, men den må vente på tråd 2 og 3 og riktige data igjen.

Således, i barrieresynkronisering av flere tråder vil det alltid være noen få tråder som vil ende opp med å vente på andre tråder, slik som i eksemplet ovenfor, venter tråd 1 på tråd 2 og 3. Dette resulterer i alvorlig forringelse av prosessytelsen.

Barriere -synkroniserings -ventefunksjonen for den tredje tråden kan representeres som:

(Wbarrier) i = f ((Tbarrier) i, (Rthread) i)

Der Wbarrier er ventetiden for en tråd, er Tbarrier antall tråder som har kommet, og Rthread er ankomsthastigheten for tråder.

Eksperimenter viser at 34% av den totale gjennomføringstiden brukes på å vente på andre tregere tråder.

Semaforer

Hovedartikkel: Semafor (programmering)

Semaforer er signalmekanismer som kan gi en eller flere tråder/prosessorer tilgang til en seksjon. En semafor har et flagg som har en viss fast verdi knyttet til det, og hver gang en tråd ønsker å få tilgang til seksjonen, reduseres det flagget. På samme måte, når tråden forlater seksjonen, økes flagget. Hvis flagget er null, kan ikke tråden få tilgang til seksjonen og blir blokkert hvis den velger å vente.

Noen semaforer tillater bare én tråd eller prosess i kodeseksjonen. Slike Semaforer kalles binær semafor og ligner veldig på Mutex. Her, hvis verdien av semafor er 1, har tråden tilgang, og hvis verdien er 0, nektes tilgangen.

Matematiske grunnlag

Synkronisering var opprinnelig et prosessbasert konsept der en lås kunne oppnås på et objekt. Den primære bruken var i databaser. Det er to typer (fil) lås ; skrivebeskyttet og lese-skrive. Bare skrivebeskyttede låser kan oppnås ved mange prosesser eller tråder. Lesere - forfatterlåser er eksklusive, ettersom de bare kan brukes av en enkelt prosess/tråd om gangen.

Selv om låser ble avledet for fildatabaser, deles data også i minnet mellom prosesser og tråder. Noen ganger er mer enn ett objekt (eller fil) låst om gangen. Hvis de ikke er låst samtidig, kan de overlappe hverandre, noe som forårsaker et fastlåst unntak.

Java og Ada har bare eksklusive låser fordi de er trådbaserte og er avhengige av instruksjonene for sammenligning og bytte av prosessorer.

Et abstrakt matematisk grunnlag for synkronisering primitiver er gitt av historien monoid . Det er også mange teoretiske enheter på høyere nivå, for eksempel prosessberegninger og peternett , som kan bygges på toppen av historiens monoid.

Eksempler på synkronisering

Følgende er noen synkroniseringseksempler med hensyn til forskjellige plattformer.

Synkronisering i Windows

Windows gir:

Synkronisering i Linux

Linux gir:

Aktivering og deaktivering av forberedelse av kjerner erstattet spinlocks på enprosessorsystemer. Før kjerneversjon 2.6 deaktiverte Linux avbrudd for å implementere korte kritiske seksjoner. Siden versjon 2.6 og nyere er Linux fullstendig forebyggende.

Synkronisering i Solaris

Solaris gir:

Pthreads -synkronisering

Pthreads er et plattformuavhengig API som gir:

  • mutexes;
  • tilstandsvariabler;
  • lesere – skribentlåser;
  • spinlocks;
  • barrierer .

Datasynkronisering

Hovedartikkel: Datasynkronisering
Image
Figur 3: Endringer fra både server og klient (er) synkroniseres.

Et tydelig annet (men relatert) konsept er datasynkronisering . Dette refererer til behovet for å beholde flere kopier av et datasett sammenhengende med hverandre eller for å opprettholde dataintegritet , figur 3. For eksempel brukes databasereplikering for å holde flere kopier av data synkronisert med databaseservere som lagrer data på forskjellige steder .

Eksempler inkluderer:

  • Filsynkronisering , for eksempel synkronisering av en håndholdt MP3-spiller til en stasjonær datamaskin;
  • Cluster -filsystemer , som er filsystemer som opprettholder data eller indekser på en sammenhengende måte på tvers av en hel dataklynge ;
  • Cache -sammenheng , vedlikehold av flere kopier av data synkronisert på tvers av flere cacher ;
  • RAID , hvor data skrives redundant på tvers av flere disker, slik at tap av en disk ikke fører til tap av data;
  • Databasereplikering , der kopier av data på en database holdes synkronisert, til tross for mulig stor geografisk adskillelse;
  • Journalføring , en teknikk som brukes av mange moderne filsystemer for å sikre at filmetadata oppdateres på en disk på en sammenhengende og konsekvent måte.

Utfordringer i datasynkronisering

Noen av utfordringene som bruker kan møte i datasynkronisering:

  • dataformater kompleksitet;
  • sanntid;
  • datasikkerhet;
  • datakvalitet;
  • opptreden.

Dataformatets kompleksitet

Dataformater har en tendens til å bli mer komplekse med tiden etter hvert som organisasjonen vokser og utvikler seg. Dette resulterer ikke bare i å bygge enkle grensesnitt mellom de to programmene (kilde og mål), men også i et behov for å transformere dataene mens de overføres til målprogrammet. ETL (extraction transformation loading) -verktøy kan på dette stadiet være nyttig for å håndtere kompleksitet i dataformat.

Sanntid

I sanntidssystemer ønsker kundene å se nåværende status for bestillingen i e-butikk, nåværende status for en pakkelevering-en sanntids pakkesporing-, nåværende saldo på kontoen sin, etc. Dette viser behovet for et sanntidssystem, som også oppdateres for å muliggjøre jevn produksjonsprosess i sanntid, f.eks. bestilling av materiale når virksomheten er tom for lager, synkronisere kundebestillinger med produksjonsprosesser, etc. Fra det virkelige liv eksisterer det så mange eksempler der sanntidsbehandling gir vellykkede og konkurransefortrinn.

Datasikkerhet

Det er ingen faste regler og retningslinjer for å håndheve datasikkerhet. Det kan variere avhengig av systemet du bruker. Selv om sikkerheten opprettholdes riktig i kildesystemet som fanger opp dataene, må sikkerhets- og informasjonstilgangsrettighetene også håndheves på målsystemene for å forhindre potensielt misbruk av informasjonen. Dette er et alvorlig problem, og spesielt når det gjelder håndtering av hemmelig, konfidensiell og personlig informasjon. Så på grunn av sensitiviteten og konfidensialiteten må dataoverføring og all mellomliggende informasjon være kryptert.

Datakvalitet

Datakvalitet er en annen alvorlig begrensning. For bedre administrasjon og for å opprettholde god kvalitet på data er vanlig praksis å lagre dataene på ett sted og dele med forskjellige mennesker og forskjellige systemer og/eller applikasjoner fra forskjellige steder. Det hjelper med å forhindre inkonsekvenser i dataene.

Opptreden

Det er fem forskjellige faser involvert i datasynkroniseringsprosessen:

Hvert av disse trinnene er kritisk. Ved store datamengder må synkroniseringsprosessen planlegges og utføres nøye for å unngå negativ innvirkning på ytelsen.

Se også

Referanser

  • Schneider, Fred B. (1997). På samtidig programmering . Springer-Verlag New York, Inc. ISBN 978-0-387-94942-0.

Eksterne linker