harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: svn commit: r824006 - in /harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net: DatagramPacket.java DatagramSocket.java
Date Wed, 14 Oct 2009 09:17:09 GMT
On 13/Oct/2009 19:59, Jesse Wilson wrote:
> 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.

Thanks Jesse,

I can't imagine that any application would rely on the methods being
synchronized (as opposed to the fields being consistent), but I agree
that we should leave it alone for compatibility sake.

Unfortunately there are quite a few places where the RI implementation
leaves a bit to be desired -- which always makes it tempting to build a
better Java :-)

Regards,
Tim

Mime
View raw message