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: r824006 - in /harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net: DatagramPacket.java DatagramSocket.java
Date Tue, 13 Oct 2009 18:59:00 GMT
On Mon, Oct 12, 2009 at 7:18 PM, Nathan Beyer <nbeyer@gmail.com> wrote:

> Honestly, the synchronization probably isn't appropriate on any of the
> accessor/mutators - the granularity isn't correct. The locking
> probably needs to encompass the entire method on DatagramSocket while
> working on a particular DatagramPacket. Realistically, you don't want
> the packet to change while processing.
>

A test shows that the RI uses synchronized. The following program doesn't
complete:

  public static void main(String[] args) throws Exception {
    byte[] data = new byte[] { 1, 2, 3, 4, 5 };
    final DatagramPacket datagramPacket = new DatagramPacket(data,
data.length);

    ExecutorService executorService = Executors.newFixedThreadPool(1);

    synchronized (datagramPacket) {
      Future<byte[]> future = executorService.submit(new Callable<byte[]>()
{
        public byte[] call() throws Exception {
          return datagramPacket.getData();
        }
      });

      byte[] fromAnotherThread = future.get();
      System.out.println(Arrays.toString(fromAnotherThread));
    }
  }


Unfortunately, the concurrency support is shallow and not useful. Despite
the fact that the RI has synchronized statements, it fails to defensively
copy the data array:

  public static void main(String[] args) throws Exception {
    byte[] data = new byte[] { 1, 2, 3, 4, 5 };
    final DatagramPacket datagramPacket = new DatagramPacket(data,
data.length);
    System.out.println("arrays are defensively copied? " + (data !=
datagramPacket.getData()));
  }


As a consequence, one thread could mutate the data array while another
thread is consuming it.

Regardless, it looks like synchronized and no defensive copying is the key
to compatibility with the RI.

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