Delt ressource ==Konflikt
At skrive til en normal fil er per definition en serialiseret operation. Du opnår ingen ydeevne ved at prøve at skrive til den fra flere tråde, I/O er en endelig afgrænset ressource i størrelsesordener mindre båndbredde end selv den langsomste eller mest overbelastede CPU.
Samtidig adgang til en delt ressource kan være kompliceret (og langsom)
Hvis du har flere tråde, der laver dyre beregninger, har du muligheder, hvis du bare bruger flere tråde, fordi du tror, du vil fremskynde noget, vil du bare gøre det modsatte. Strid om I/O sænker altid adgangen til ressourcen, den fremskynder den aldrig på grund af låseventer og andre overhead.
Du skal have en kritisk sektion, der er beskyttet og kun tillader en enkelt forfatter ad gangen. Du skal bare slå kildekoden op for enhver logningsskriver, der understøtter samtidighed, og du vil se, at der kun er en enkelt tråd, der skriver til filen.
Hvis din ansøgning primært er:
-
CPU bundet: Du kan bruge en eller anden låsemekanisme/datakonstruktion til kun at lade én tråd ud af mange skrive til filen ad gangen, hvilket vil være ubrugeligt fra et samtidighedssynspunkt som en naiv løsning; Hvis disse tråde er CPU-bundet med lidt I/O, kan dette muligvis fungere.
-
I/O bundet: Dette er det mest almindelige tilfælde, du skal bruge et meddelelsessystem med en kø af en slags og få alle trådene til at sende til en kø/buffer og trække en enkelt tråd fra den og skrive til filen. Dette vil være den mest skalerbare og nemmeste at implementere løsning.
Journaling - Asynkrone skrivninger
Hvis du har brug for at oprette en enkelt super stor fil, hvor rækkefølgen af skrivninger er ligegyldig, og programmet er CPU bundet, kan du bruge en journaliseringsteknik.
Har hver process skriv til en separat fil og sammensæt derefter de flere filer til en enkelt stor fil til sidst. Dette er en meget gammel skole lavteknologi løsning, der fungerer godt og har gjort det i årtier.
Jo mere lager I/O du har, jo bedre vil dette naturligvis yde på den endelige konkat.