On 2010-07-06 22:49, Jesse Wilson wrote:
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.
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 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.
--
Best Regards,
Regis.
