Under normale omstændigheder, så længe multitrådet programmering er involveret, vil programmets kompleksitet stige betydeligt, ydeevnen vil falde betydeligt, og sandsynligheden for fejl vil være betydeligt øget.
Multitrådet programmering er beregnet til at køre et program parallelt for at forbedre databehandlingskapaciteten, men i de fleste tilfælde indebærer det konkurrence om delte ressourcer, så det skal låses, når ressourceobjekter ændres. Der er dog mange måder at implementere låse på, så lad os se på implementeringen og ydeevnen af flere typer låse i C#.
Flere måder at bruge låse på
1. Atomlås
Opnå "låseløs" konkurrence gennem atomoperationen Interlocked.CompareExchange.
Den officielle forklaring er at levere atomare operationer for variable, der deles af flere tråde. Navnerum: System.Threading
2. Kritisk område
Serialisering af flere tråde for at få adgang til offentlige ressourcer eller et stykke kode er hurtigt og velegnet til at kontrollere dataadgang. Låsesyntaksen i C# er et syntakssukker for det kritiske område (Monitor).
3. Atomar operationer
Atomare operationer, som er et specialtilfælde, er iboende trådsikre, så der er ikke behov for at låse dem.
Officielt fortolket som en øgelig værdi af en given variabel i form af en atomar operation og lagring af resultatet. Navnerum: System.Threading
4. Læs og skriv lås
Læse-skrive-låse tillader læsning af ressourcer, når andre programmer skriver, så hvis ressourcen tillader beskidte læsninger, er dette mere passende.
Den officielle forklaring angiver en låst tilstand, der bruges til at styre ressourceadgang, hvilket muliggør multitrådede læsninger eller eksklusiv skriveadgang. Navnerummet er System.Threading
5. Semafor
Semaforer, designet til at kontrollere et begrænset antal brugerressourcer.
Den officielle forklaring begrænser antallet af tråde, der kan tilgå en ressource eller ressourcepulje samtidig. Navnerummet er System.Threading
6. Begivenheder
Bruges til at underrette tråden om, at nogle hændelser er sket, hvilket starter starten på en efterfølgende opgave.
Den officielle forklaring angiver, at trådsynkroniseringsbegivenheder automatisk nulstilles, når et signal modtages efter at en tråd er frigivet. Sådanne typer kan ikke arves.
7. Gensidig udelukkelse
Der findes en Mutex-klasse i C#, lige under System.Threading-navnerummet, Mutex er faktisk en mutex, som ikke kun kan håndtere ressourcekonkurrence mellem flere tråde, men også ressourcekonkurrence mellem processer.
Ydelsestestkode
Kør koden
Resultater fra præstationstest
Bemærk: De ovenstående data er kun resultatet af hardwareydelsen i det aktuelle testmiljø og kan kun sammenlignes med hinanden.
1) I forskellige tests er det bestemt hurtigst at undgå låsning, så prøv at undgå ressourcekonkurrence, der fører til låst drift.
2) Interlocked.CompareExchange viser konsekvent bedre ydeevne i multi-threading og ligger nummer to.
3) Den tredje lås, den kritiske zone, viser også god ydeevne, så modbevis venligst andre, når de siger, at låsens ydeevne er lav.
4) Den fjerde plads er atomar variable (atom) operation, men i øjeblikket understøtter den kun selvforøgelse og subtraktion af variable, og anvendeligheden er ikke stærk.
5) Ydelsen af den femte læse-/skrivelås (ReaderWriterLockSlim) er også okay, og den understøtter ikke læsning, og praktisk anvendelighed er stadig relativt god.
6) De resterende semaforer, begivenheder og mutex har den dårligste ydeevne, selvfølgelig har de deres eget anvendelsesområde, men de klarer sig ikke godt i forhold til ressourcekonkurrence.
Original linkadresse:Hyperlink-login er synlig.
|
Opslået den 2023-4-13 18:44:49
|
|
|
|
Udlejer|
Opslået den 13-4-2023 18:46:52
|
Opslået den 13-4-2023 kl. 19:21:44
|
