Comments on: Když na prostředí záleží aneb soubory a více vláken http://blog.krecan.net/2006/07/24/kdyz-na-prostredi-zalezi-aneb-soubory-a-vice-vlaken/ Short remarks from Java world Wed, 08 Sep 2010 10:08:11 +0200 http://wordpress.org/?v=2.9.2 hourly 1 By: Maaartin http://blog.krecan.net/2006/07/24/kdyz-na-prostredi-zalezi-aneb-soubory-a-vice-vlaken/comment-page-1/#comment-476 Maaartin Tue, 20 May 2008 19:35:05 +0000 http://blog.krecan.net/?p=5#comment-476 Pro synchronizaci v ramce jedny JVM bych nepouzival FileLock. Dalo by se zneuzit synchronized (file.toString().intern()) {...} ale to by opravdu bylo zneuziti String-u. Pokud to napadne jeste nekoho jinyho, bude problem. Ale staci udelat si vlastni pool nakych objektu. > Linux (alespoň moje verze na extfs3) soubor smaže, ale čtoucí vlákno ho nějakým zázračným způsobem může dočíst. To neni zazrak: Tam jen pochopili, ze smazani souboru je pouze jeho odstraneni z adresare. Na fyzicke existenci souboru to nic nemeni (smazne se az nebude potreba, neco jako GC zalozeny na reference counting). Pro synchronizaci v ramce jedny JVM bych nepouzival FileLock. Dalo by se zneuzit
synchronized (file.toString().intern()) {...}
ale to by opravdu bylo zneuziti String-u. Pokud to napadne jeste nekoho jinyho, bude problem. Ale staci udelat si vlastni pool nakych objektu.

> Linux (alespoň moje verze na extfs3) soubor smaže, ale čtoucí vlákno ho nějakým zázračným způsobem může dočíst.

To neni zazrak: Tam jen pochopili, ze smazani souboru je pouze jeho odstraneni z adresare. Na fyzicke existenci souboru to nic nemeni (smazne se az nebude potreba, neco jako GC zalozeny na reference counting).

]]>