harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Beyer <nbe...@gmail.com>
Subject Re: svn commit: r824006 - in /harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net: DatagramPacket.java DatagramSocket.java
Date Thu, 15 Oct 2009 02:34:17 GMT
On Wed, Oct 14, 2009 at 4:17 AM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> 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 :-)

In some circles, synchronized is just an implementation detail and not
a definition of the interface. I think that may be on the SCJP test.
We could consider that unless the synchronization characteristics are
defined by the documentation, then don't have to abide by the same
implementation details.

-Nathan

>
> Regards,
> Tim
>

Mime
View raw message