On 2010-07-06 22:49, Jesse Wilson wrote: > On Sun, Jul 4, 2010 at 8:05 PM, wrote: > >> File.counter could be accessed by multiple threads, so use AtomicInteger to >> make >> sure each thread using different int value to create temp file. > > > Is this a sufficient fix for the problem? The file system may be shared by > multiple concurrently-executing VMs. Coordinating access to temp files > within a single VM doesn't prevent other processes from grabbing the same > file names. > > A more robust solution might involve including the VM's process ID in the > filename. Or perhaps some kind of create-and-test protocol in a loop. > At r961242, I used counter value generated first time to identify different VM instances, I think that's enough to avoid name conflicts. > > On Tue, Jul 6, 2010 at 6:56 AM, Mark Hindesswrote: > >> This breaks the build for the IBM VME (from developerWorks). Since they >> don't have a sun.misc.Unsafe, so the AtomicInteger can't be resolved. >> > > If VME is to stay modern, they're going to need to support > java.util.concurrent. I don't think Harmony should provide a > lowest-common-denominator class library; supporting systems that don't have > j.u.c is an unnecessary handicap. > > Particularly since they can implement AtomicInteger using less efficient > concurrency primitives. There's even a full > backportthat could close some > gaps if the standard java.util.concurrent isn't > feasible for their VM. > -- Best Regards, Regis.