Delad resurs ==Konflikt
Att skriva till en normal fil är per definition en serialiserad operation. Du får ingen prestanda genom att försöka skriva till den från flera trådar, I/O är en ändlig begränsad resurs med storleksordningar mindre bandbredd än till och med den långsammaste eller mest överbelastade CPU:n.
Samtidig åtkomst till en delad resurs kan vara komplicerad (och långsam)
Om du har flera trådar som gör dyra beräkningar så har du alternativ, om du bara använder flera trådar för att du tror att du kommer att påskynda något, kommer du bara att göra tvärtom. Konflikt om I/O saktar alltid ner åtkomsten till resursen, den snabbar aldrig upp den på grund av låsväntningar och andra omkostnader.
Du måste ha en kritisk sektion som är skyddad och endast tillåter en enda författare åt gången. Leta bara upp källkoden för alla loggningsförfattare som stöder samtidighet så ser du att det bara finns en enda tråd som skriver till filen.
Om din ansökan huvudsakligen är:
-
CPU-bunden: Du kan använda någon låsmekanism/datakonstruktion för att bara låta en tråd av många skriva till filen åt gången, vilket kommer att vara värdelöst ur en samtidighetssynpunkt som en naiv lösning; Om dessa trådar är CPU-bundna med lite I/O kan detta fungera.
-
I/O bundet: Det här är det vanligaste fallet, du måste använda ett system för att skicka meddelanden med en kö av något slag och låta alla trådar lägga upp till en kö/buffert och dra en enda tråd från den och skriva till filen. Detta kommer att vara den mest skalbara och enklaste att implementera lösningen.
Journaling - Async Writer
Om du behöver skapa en enda superstor fil där skrivordningen är oviktig och programmet är CPU-bundet kan du använda en journalteknik.
Ha varje process skriv till en separat fil och sammanfoga sedan flera filer till en enda stor fil i slutet. Det här är en mycket gammal lågteknologi lösning som fungerar bra och har gjort i decennier.
Uppenbarligen mer lagrings-I/O du har desto bättre kommer detta att prestera på slutkonkatet.