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: [classlib][nio] How to deal with unstable but useful tests?
Date Tue, 11 Jul 2006 16:47:47 GMT
Geir Magnusson Jr wrote:
> Don't we want to be able to tell if a thread is Blocked anyway?

Do you mean on a monitor (=yes) or in the OS?  The VM may choose to do
deadlock detection etc. but the classlib doesn't care.

Regards,
Tim

> Tim Ellison wrote:
>> I hadn't appreciated that the read call is blocking...
>>
>> So how about you do the blocking read() in a new thread, then the main
>> thread can poll to wait until the reading thread's state is Blocked,
>> before closing the channel and forcing the exception?
>>
>> The problem is that the thread will be detached from the VM and blocking
>> in the OS for the read, so not officially Java Blocked.  You can only
>> determine OS blocked state via additional native code.
>>
>> Therefore, as Paulex wrote, if you are not writing additional native
>> code for your test you may have to actually synchronize on the reading
>> thread having passed begin(), not when it is actually read() blocked.
>>
>> Does that make sense?
>>
>> Regards,
>> Tim
>>
>> Andrew Zhang wrote:
>>> Hello Tim,
>>>
>>> Thank you for your suggestion. :)
>>>
>>> Of course, "fix" is the best choice. I also have tried to use
>>> "wait/notify",
>>> but found it didn't work for this case.
>>>
>>> Please note that "channel1.read(targetBuf); // Label 3" is a blocking
>>> operation. And we want code at label 1,2 to execute after label 3.
>>>
>>> There is the question:
>>>
>>> Where should I put "notify"?
>>>
>>> 1. before "read"? NO. If nofity is put before read, then we still can't
>>> guarantee "configureBlocking" is executed after read.
>>> 2. after "read"? NO. read is a blocking operatoin. It will never be
>>> executed
>>> if put notify after read.
>>> 3. in "read"?  Obviously NO.
>>>
>>> Please correct me if I'm wrong.
>>>
>>> Thanks!
>>>
>>>
>>> On 7/11/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>>> Andrew Zhang wrote:
>>>>> Hello everybody,
>>>>>
>>>>> I noticed such tests in DatagramChannel, which is useful, but
>>>> potentially
>>>>> unstable.  Consider:
>>>>>
>>>>> public void testReadWrite_configureBlock() throws Exception {
>>>>>        byte[] targetArray = new byte[2];
>>>>>        // bind and connect
>>>>>        this.channel1.socket().bind(localAddr2);
>>>>>        this.channel1.connect(localAddr1);
>>>>>        this.channel2.socket().bind(localAddr1);
>>>>>        this.channel2.connect(localAddr2);
>>>>>        ByteBuffer targetBuf = ByteBuffer.wrap(targetArray);
>>>>>
>>>>>        new Thread() {
>>>>>            public void run() {
>>>>>                try {
>>>>>                    Thread.sleep(TIME_UNIT);
>>>>>                    channel1.configureBlocking(false); // Label 1
>>>>>                    channel1.close(); // Label 2
>>>>>                } catch (Exception e) {
>>>>>                    //ignore
>>>>>                }
>>>>>            }
>>>>>        }.start();
>>>>>        try {
>>>>>            this.channel1.read(targetBuf); // Label 3
>>>>>            fail("should throw AsynchronousCloseException");
>>>>>        } catch (AsynchronousCloseException e) {
>>>>>            // ok
>>>>>        }
>>>>>    }
>>>>> This test assumes Label 3  code should execute before Label 1 and Label
>>>> 2,
>>>>> which is right in most cases, because the code invokes "Thread.sleep
>>>>> (TIME_UNIT)".
>>>>>
>>>>> However, it's potentially unstable. It heavily depends on TIME_UNIT
>>>> value,
>>>>> test environment (Hardware, OS ...)
>>>> Urgh.  There are *very* few occasions when you need to use
>>>> Thread.sleep(); and 'thread synchronization' is definitely not one of
>>>> them!
>>>>
>>>> If you have order dependencies between two or more threads then use
>>>> wait/notify, or synchronized, and make them explicit.
>>>>
>>>> There are any number of books on multi-threaded programming in Java.
>>>>
>>>>> Indubitably, the test is very useful for testing
>>>>> "AsynchronousCloseException" of DatagramChannel.read(ByteBuffer)
>>>> method.
>>>>> How shall we deal with such issue?  Deleting such valuable tests is not
>>>> a
>>>>> wise decision, while keeping them may cause build system fail.
>>>>>
>>>>> One solution I could image is TestNG. :) i.e. Use "@dev" or
>>>> something to
>>>>> mark such tests, say, the tests are only for developing purpose.
>>>>>
>>>>> Any suggestions?
>>>> Fix it!  :-)
>>>>
>>>> Regards,
>>>> Tim
>>>>
>>>> -- 
>>>>
>>>> Tim Ellison (t.p.ellison@gmail.com)
>>>> IBM Java technology centre, UK.
>>>>
>>>> ---------------------------------------------------------------------
>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>
>>>>
> 
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message