Visszairas: Write ahead log. Irod a fajl (logikai) vegere a valtozasokat, majd ha a sikerult leirni rendesen, akkor allitod at a mutatot arra, hogy az uj lapra mutasson. (RDBMS-ek rendszerint lapokban dolgoznak, az a legkisebb egyseg amit hajlando irni/olvasni.) Nagy vonalakban ez az elve az osszes journaling megoldasnak, ami pont arra szolgal, hogy egyreszt biztonsagosan meglegyenek az adataid (aramszunet, fagyas, stb. beleertve), masreszt atomi muveletkent kezelodjon. Szoval nyitott kapukat dongetsz.
De ugyanez igaz a plistre: ott sem az eredeti fajlt irod felul, hanem egy uj, ideiglenees fajlba kezded el kiirni a modositasokat, majd fogod es lecsereled az eredeti fajlt. Nem veletlen, hogy a Windows nyujt erre fuggvenyt (WinAPI es .NET egyarant), holott igazabol egy-ketto rename es egy delete lenne ossz-vissz.
Masreszt jo esellyel biztos lehetsz abban, hogy a registry C-ben (esetleg C++-ban) van megirva. Azt sajnos nem tudom, hogy kernel vagy userspace, sajnos nincs keznel Windows Internals, hogy megnezhessem. De ha tippelnem kellene userspace, elvegre tobb keres jon a registrybol az userspace felol, mint kernelspace felol.
Egy RDBMS eseten is rengeteg kernel space kod mozog: halozat, io, processek kozti valtas, stb. Megjegyzem, idekeverni az RDBMS-eket megint csusztatas, masra van optimalizalva. Ha azokat is elkezdened key-value storagenak hasznalni, az se lenne olyan gyors, sot, merem allitani, hogy joval lassabb, mint a registry. Akar egy sqlite, ami kb. parba allithato lenne egy osszehasonlitashoz.
RDBMS-eknek meg egesz mas celbol van dedikalt eroforras-keszlete. Masreszt ismetelten irom: nem kell lockolni az irashoz. Nem tudom, hogy honnan szedted, hogy barmi ilyenhez kell lockolas.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™