* Matthew Toseland <toad at amphibian.dyndns.org> [2008-04-05 11:11:05]:
> On Saturday 05 April 2008 03:50, Florent Daigni?re wrote: > > * Matthew Toseland <toad at amphibian.dyndns.org> [2008-04-04 19:22:27]: > > > > > On Friday 04 April 2008 07:05, nextgens at freenetproject.org 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. That's not what it says... it only says that the ++ operator isn't atomic. As far as I know "++" is translated as x = x + 1 in bytecode (which isn't done in one operation) ... So it's obvious it's not atomic. > > 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... I've seen reports of FCP not reporting inserts completion, yes. Arguably not much recently but it's not like there was an active development of FCP apps going on... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080405/e2d0aba1/attachment.pgp>
