On Saturday 05 April 2008 03:50, Florent Daignière wrote: > * Matthew Toseland <[EMAIL PROTECTED]> [2008-04-04 19:22:27]: > > > On Friday 04 April 2008 07:05, [EMAIL PROTECTED] wrote: > > > Author: nextgens > > > Date: 2008-04-04 06:05:54 +0000 (Fri, 04 Apr 2008) > > > New Revision: 18975 > > > > > > Modified: > > > trunk/freenet/src/freenet/client/async/SplitFileInserterSegment.java > > > Log: > > > Simplify a few things synchronization-wise declaring a few variables > > volatile > > > > I thought there were issues with volatile? Like it's not deterministic, and > > you really should use locking in all nontrivial cases? > > I suggest you read > http://www.javaperformancetuning.com/tips/volatile.shtml :)
"Note however that volatile has been incompletely implemented in most JVMs. Using volatile may not help to achieve the results you desire (yes this is a JVM bug, but its been low priority until recently)." Presumably this doesn't include the mainline Sun VM. "NOTE THE TIP "volatile primitive datatypes have atomic ++ operations" HAS BEEN SHOWN TO BE INVALID" So never use volatile integers/longs/shorts. Hmmm. > > Two things to add: > 1) there is no significant performance cost for > reading a volatile on x86 > 2) The SplitFileInserterSegment class is already a synchronization > nightmare so we'd better reduce the locking to the minimum there : we still > had some unsynchronized accesses to those booleans. > > I think that making those booleans volatile is a step forward fighting > the "requests don't finish" kind of bugs which are likely to be > caused by race-conditions. > Have you seen complaints of splitfile *inserts* not finishing? AFAIK reports are generally of requests not finishing...
pgpV9X7AbXT3X.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
