harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Wilson <jessewil...@google.com>
Subject Re: svn commit: r960424 - /harmony/enhanced/java/trunk/classlib/modules/luni/src/main/java/java/io/File.java
Date Tue, 06 Jul 2010 14:49:49 GMT
On Sun, Jul 4, 2010 at 8:05 PM, <regisxu@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.hindess@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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message