On Sun, Jul 4, 2010 at 8:05 PM, <regi...@apache.org> 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. On Tue, Jul 6, 2010 at 6:56 AM, Mark Hindess <mark.hind...@googlemail.com>wrote: > 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 backport<http://backport-jsr166.sourceforge.net/>that could close some gaps if the standard java.util.concurrent isn't feasible for their VM.
