Er der nogen specifikke anvendelsessager, hvor mutexes er betydeligt hurtigere end kanaler

Grundlæggende forskelle, der påvirker ydeevnen

Mutexes giver gensidig udelukkelse ved kun at lade en tråd eller goroutine adgang til et kritisk afsnit ad gangen. Internt involverer en Mutex-operation typisk atominstruktioner og kan involvere blokering af kerne-niveau kun, når der er påstand. På grund af dette koster det ikke -opførte Mutex -lås/låsningsoperationer ofte kun et par nanosekunder.

Kanaler er derimod abstraktioner på højere niveau designet til kommunikation mellem goroutiner eller tråde. At sende eller modtage på en kanal involverer styring af en kø, mulige hukommelsesallokeringer, planlægning af goroutiner og vågne dem op, hvis de sover. Denne overhead betyder endda enkle tilstandsmutationer, der er beskyttet af en kanal, der pådrager sig flere omkostninger sammenlignet med en mutex på grund af kontekstskift og koordineringsarbejde.

Disse grundlæggende forskelle indikerer allerede, hvorfor mutexes generelt er hurtigere, for enkel delte variabel beskyttelse eller kritiske sektioner.

Brug sager, hvor mutexes er hurtigere

Enkel delt statsbeskyttelse

Når et program skal beskytte delte variabler  såsom tællere, kort eller enkle flag  Mutexes er meget hurtigere, da det kritiske afsnit involverer minimal synkroniseringsomkostning. Eksempler inkluderer:

- Tællingsanmodninger på en webserver: Hver anmodning om anmodning om anmodning kan beskyttes af en mutex uden at kræve omkostningen af ​​at sende beskeder gennem en kanal, der tilføjer kø og planlægning af forsinkelser. Mutexes tillader ligetil, direkte adgang og har vist sig at forbedre gennemstrømningen med en størrelsesorden eller mere.

- Adgang til delte cacher eller kort: Beskyttelse af datastrukturer med Mutexes tilbyder inline -læsninger og skriver med minimal overhead. Brug af kanaler som formidlere her introducerer ekstra latenstid, da enhver adgang bliver en anmodning om anmodning-respons.

Benchmark-tests viser, at Mutex-baserede tællere kan være ca. 75 gange hurtigere end kanalbaserede tællere på grund af den reducerede overhead i synkronisering og undgå omkostningerne ved køstyring og kontekstskift, der er forbundet med kanaler.

Lav påstemning eller ubestridte scenarier

I miljøer med lavt strid er Mutex Lock og Unlock Operations næsten bare atomoperationer uden ventetider. Det ubestridte tilfælde er, hvor Mutexes skinner, da låsen er let og normalt ikke udløser planlægning af kerneniveau.

Kanaler pådrager sig imidlertid omkostninger selv i lav påstand, fordi hver send/modtagelse involverer mere kompleks styring, buffering og synkronisering. For et lille antal goroutiner eller i scenarier med lidt strid overgår Mutexes således markant.

Høj samtidighed med simpel låsning

I scenarier, hvor mange goroutiner udfører meget korte kritiske sektioner, der ændrer delt tilstand, har Mutexes stadig en tendens til at være mere effektive end kanaler. Den vigtigste årsag er, at Mutexes blokerer for at kæmpe goroutiner i kernen, hvilket tillader effektiv planlægning og vågner nøjagtigt en goroutine, når den låses op. Kanaler involverer på den anden side aktiv goroutine -planlægning og køstyring, der skaber overhead under belastning.

For eksempel viser benchmarks, hvor op til 10 goroutiner er involveret, at mutexer er flere gange hurtigere, og Mutexes forbliver konkurrencedygtige, selv med hundreder af goroutiner.

Arbejdsfordeling, når statsmutationer er minimale

Til styring af skiver eller lister over opgaver kan Mutexes være hurtigere, når du låser kort for at pop eller skubbe opgaver. Selvom kanaler er meget naturlige til opgavedistribution, hvis det kritiske afsnit er kort og den delte tilstand kræver hurtig låsning og låsning, undgår mutexes det ekstra overhead af kanalkoordination og bringer bedre gennemstrømning.

I mange virkelige verdenssystemer, såsom arbejderpooler eller jobkøer, kan Mutexes være enklere og hurtigere til styring af opgavelister sammenlignet med kanaler.

Hvorfor mutexes er hurtigere i disse tilfælde

- Nedre overhead: Mutexes Brug atomiske CPU -instruktioner direkte til låsning og låsning, ofte uden kontekstafbryder eller dyre planlægningsbeslutninger.

- Kernelblokering med kø: Korpende goroutiner sover effektivt på mutexer effektivt, danner en kø, og planlæggeren vågner dem serielt. Kanaler forårsager mere komplekse vågnings- og planlægningsmønstre.

- Ingen meddelelsesomkostninger: Kanaler skal tildele buffere eller køindgange og kopierings-/overførselsdata, hvilket er unødvendigt, når simpelt ejerskab og eksklusivitet er nok.

- Direkte hukommelsesadgang: Mutexes tillader direkte hukommelsesadgang inden for et kritisk afsnit, mens kanaler kræver at sende data gennem et kommunikationsmedium og tilføje lag af indirekte og latenstid.

Kontekster mindre egnede til kanaler

Selvom kanaler giver en elegant og sikker måde at kommunikere mellem goroutiner på og er meget værdifulde til rørledningsbehandling og begivenhedshåndtering, gør deres overhead dem mindre egnede til korte, hyppige delte statsmutationer.

Kanaler er ideelle, når man synkroniserer komplekse beregninger, der involverer flere goroutiner, hvor meddelelsespassende semantik er naturlige og gavnlige. Men for enkel låsning skinner Mutexes.

Eksperimentelle og benchmark -bevis

- Benchmarks med Go's synkronisering Primitiver viser, at Mutex -tællere fungerer med latenser i nanosekunderne, mens kanal tællere er størrelsesordener langsommere (f.eks. 0,8 ns mod 60 ns pr. Betjening).

- Præstation vender kun ved meget høje skalaer (f.eks. Tusinder af goroutiner), når kanaler kan overgå mutexes i nogle tilfælde, da kanaler undgår at låse overhead og bedre model samtidige rørledninger.

- Under strid overgår Mutexes spinlocks på grund af planlægningseffektivitet på kerneniveau.

- Mutexes undgår hukommelsesallokeringer og kontekstskift, der er til stede i kanaler, hvilket fører til betydelige gevinster i gennemstrømning og lavere CPU -brug til beskyttelse af delte variabler.

Sammendrag af brugssagsanbefalinger

- Brug Mutexes, når du beskytter delt hukommelse eller mutabel tilstand, der er adgang til samtidig, især hvis det kritiske afsnit er kort og involverer enkle operationer.

- Brug kanaler til orkestrering af beregninger, rørledninger og begivenhedsdrevne arkitekturer, hvor meddelelser repræsenterer statslige eller opgaver, der skal behandles asynkront.

- For præstationskritisk kode, der involverer direkte tilstandsmutationer med flere tråde eller goroutiner, giver mutexer normalt overlegen gennemstrømning og lavere latenstid.

- Overvej kanaler, når din samtidighedslogik drager fordel af meddelelsespassende semantik, men undgå dem for højfrekvente enkle låsebehov.

Teknisk dyb dykke

Mutexes bruger typisk atomoperationer som sammenligning-og-swap (CAS) til låsning og oplåsning i brugerrummet og kun gå ind i kernen, når der sker strid for at blokere tråden. Dette minimerer kontekstskift og overhead i det ubevidste tilfælde.

Kanaler implementerer FIFO -køer for meddelelser og understøttes ofte af buffere, der kan ændre størrelsen. At sende en kanal involverer at kontrollere, om modtageren er klar, kopiere data i bufferen eller blokere og planlægge den modtagende goroutine. Disse trin tilføjer omkostninger, der formerer sig med driftsfrekvens.

Mutexes søvnkonkurrende tråde og vedligehold en kø, så kun en tråd vågner ad gangen. Kanaler kan vække flere goroutiner, når meddelelser bliver tilgængelige, hvilket fører til mere kompleks planlægning og kontekstskiftomkostninger.

Konklusion

Sammenfattende er mutexer markant hurtigere end kanaler i scenarier, der kræver hurtige, enkle og hyppige delte statsmutationer med lave strid eller korte kritiske sektioner. Deres lette atomoperationsimplementering, effektiv kerneblokering og vågning af tråde og direkte hukommelsesadgang giver overlegen ydelse sammenlignet med planlægningen, kopiering og meddelelsesoverførelse af overheadkanaler pådrager sig. Kanaler er bedre egnet til at kommunikere komplekst arbejde og koordinere goroutiner, men betaler en omkostning i rå synkroniseringshastighed.