You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Sian January (JIRA)" <ji...@apache.org> on 2007/01/11 11:23:27 UTC
[jira] Created: (HARMONY-2973) [classlib] [luni] Concerns about
synchronization in java.net.InetAddress
[classlib] [luni] Concerns about synchronization in java.net.InetAddress
------------------------------------------------------------------------
Key: HARMONY-2973
URL: https://issues.apache.org/jira/browse/HARMONY-2973
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Sian January
FindBugs raised two concerns about synchronization in InetAddress.isReachableByMultiThread(...) - an unconditional wait on line 888, and also the fact that the same wait is not in a loop. Looking more closely at this method I am concerned about the synchronization because it looks like it would be possible for no notify calls to occur after that wait, which would mean the wait would continue indefinitely. It would be great if someone could take a look at this as I'm not entirely sure myself what the correct solution is.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-2973) [classlib] [luni] Concerns about
synchronization in java.net.InetAddress
Posted by "Sian January (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465430 ]
Sian January commented on HARMONY-2973:
---------------------------------------
Thanks for looking at this Mikhail. Your patch looks great and fixes the FindBugs complaints. The only thing I would suggest is that you might want to make the wait on line 899 longer than 100 milliseconds, because if the notifying threads are taking a long time then that loop will be running a lot. If the notifying threads are quick then the wait will be interrupted anyway so I don't think it would be a problem waiting for longer. Maybe 1000ms or more? What do you think?
> [classlib] [luni] Concerns about synchronization in java.net.InetAddress
> ------------------------------------------------------------------------
>
> Key: HARMONY-2973
> URL: https://issues.apache.org/jira/browse/HARMONY-2973
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Sian January
> Attachments: H-2973.patch
>
>
> FindBugs raised two concerns about synchronization in InetAddress.isReachableByMultiThread(...) - an unconditional wait on line 888, and also the fact that the same wait is not in a loop. Looking more closely at this method I am concerned about the synchronization because it looks like it would be possible for no notify calls to occur after that wait, which would mean the wait would continue indefinitely. It would be great if someone could take a look at this as I'm not entirely sure myself what the correct solution is.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-2973) [classlib] [luni] Concerns about
synchronization in java.net.InetAddress
Posted by "Mikhail Markov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465485 ]
Mikhail Markov commented on HARMONY-2973:
-----------------------------------------
Sian, thanks for your review!
I think we have a trade-in here:
1) If we have longer wait timeout and we have the case when notifying threads finished before entering the main one, then we will wait for this longer timeout (1sec in your example) to go further. From this perspective the less wait timeout the less time we'll wait.
2) If we have shorter wait timeout we'll more time iterate in the cycle. Hmm.. i think that 10 additional iterations during 1 sec. is nothing for computers now and this will not lead to any significant performance gaps.
So, I'd prefere having less wait timeout as having extra iterations seems more harmless to me then waiting idle 10x more times. 100ms looks good compromise for this 2 cases to me.
> [classlib] [luni] Concerns about synchronization in java.net.InetAddress
> ------------------------------------------------------------------------
>
> Key: HARMONY-2973
> URL: https://issues.apache.org/jira/browse/HARMONY-2973
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Sian January
> Attachments: H-2973.patch
>
>
> FindBugs raised two concerns about synchronization in InetAddress.isReachableByMultiThread(...) - an unconditional wait on line 888, and also the fact that the same wait is not in a loop. Looking more closely at this method I am concerned about the synchronization because it looks like it would be possible for no notify calls to occur after that wait, which would mean the wait would continue indefinitely. It would be great if someone could take a look at this as I'm not entirely sure myself what the correct solution is.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-2973) [classlib] [luni] Concerns about
synchronization in java.net.InetAddress
Posted by "Sian January (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465722 ]
Sian January commented on HARMONY-2973:
---------------------------------------
I'm not sure about 1. Surely if the notifying threads have finished before entering the main one then either reached will be true or addrCount will be 0 so we won't wait at all? Also should the '&&' be an '||' on 897?
> [classlib] [luni] Concerns about synchronization in java.net.InetAddress
> ------------------------------------------------------------------------
>
> Key: HARMONY-2973
> URL: https://issues.apache.org/jira/browse/HARMONY-2973
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Sian January
> Attachments: H-2973.patch
>
>
> FindBugs raised two concerns about synchronization in InetAddress.isReachableByMultiThread(...) - an unconditional wait on line 888, and also the fact that the same wait is not in a loop. Looking more closely at this method I am concerned about the synchronization because it looks like it would be possible for no notify calls to occur after that wait, which would mean the wait would continue indefinitely. It would be great if someone could take a look at this as I'm not entirely sure myself what the correct solution is.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-2973) [classlib] [luni] Concerns about
synchronization in java.net.InetAddress
Posted by "Sian January (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465749 ]
Sian January commented on HARMONY-2973:
---------------------------------------
Sorry - you're right about the '&&' - not sure what I was thinking. I will set patch available now. Thanks again!
> [classlib] [luni] Concerns about synchronization in java.net.InetAddress
> ------------------------------------------------------------------------
>
> Key: HARMONY-2973
> URL: https://issues.apache.org/jira/browse/HARMONY-2973
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Sian January
> Attachments: H-2973.patch, H-2973upd.patch
>
>
> FindBugs raised two concerns about synchronization in InetAddress.isReachableByMultiThread(...) - an unconditional wait on line 888, and also the fact that the same wait is not in a loop. Looking more closely at this method I am concerned about the synchronization because it looks like it would be possible for no notify calls to occur after that wait, which would mean the wait would continue indefinitely. It would be great if someone could take a look at this as I'm not entirely sure myself what the correct solution is.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (HARMONY-2973) [classlib] [luni] Concerns about
synchronization in java.net.InetAddress
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Ellison resolved HARMONY-2973.
----------------------------------
Resolution: Fixed
Thanks Sian and Mikhail,
Patch applied to LUNI module at repo revision r504147.
Please check it was applied as you expected.
> [classlib] [luni] Concerns about synchronization in java.net.InetAddress
> ------------------------------------------------------------------------
>
> Key: HARMONY-2973
> URL: https://issues.apache.org/jira/browse/HARMONY-2973
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Sian January
> Assigned To: Tim Ellison
> Attachments: H-2973.patch, H-2973upd.patch
>
>
> FindBugs raised two concerns about synchronization in InetAddress.isReachableByMultiThread(...) - an unconditional wait on line 888, and also the fact that the same wait is not in a loop. Looking more closely at this method I am concerned about the synchronization because it looks like it would be possible for no notify calls to occur after that wait, which would mean the wait would continue indefinitely. It would be great if someone could take a look at this as I'm not entirely sure myself what the correct solution is.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-2973) [classlib] [luni] Concerns about
synchronization in java.net.InetAddress
Posted by "Sian January (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sian January updated HARMONY-2973:
----------------------------------
Patch Info: [Patch Available]
> [classlib] [luni] Concerns about synchronization in java.net.InetAddress
> ------------------------------------------------------------------------
>
> Key: HARMONY-2973
> URL: https://issues.apache.org/jira/browse/HARMONY-2973
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Sian January
> Attachments: H-2973.patch, H-2973upd.patch
>
>
> FindBugs raised two concerns about synchronization in InetAddress.isReachableByMultiThread(...) - an unconditional wait on line 888, and also the fact that the same wait is not in a loop. Looking more closely at this method I am concerned about the synchronization because it looks like it would be possible for no notify calls to occur after that wait, which would mean the wait would continue indefinitely. It would be great if someone could take a look at this as I'm not entirely sure myself what the correct solution is.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-2973) [classlib] [luni] Concerns about
synchronization in java.net.InetAddress
Posted by "Mikhail Markov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465075 ]
Mikhail Markov commented on HARMONY-2973:
-----------------------------------------
Sian, i agree with your concerns - although network operations are slow, theoretically it's possible for main thread to enter synchronized block when notify threads are already finished. Also i found improper addrCount variable handling: again, theoretically (although i think it'll never happen) it could never be zero, for example, if one of the addresses is loopback but non-local address :-) - in this case one of notifying threads will not be started and addrCount variable will not be decreased.
I'll try to improve the code.
> [classlib] [luni] Concerns about synchronization in java.net.InetAddress
> ------------------------------------------------------------------------
>
> Key: HARMONY-2973
> URL: https://issues.apache.org/jira/browse/HARMONY-2973
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Sian January
>
> FindBugs raised two concerns about synchronization in InetAddress.isReachableByMultiThread(...) - an unconditional wait on line 888, and also the fact that the same wait is not in a loop. Looking more closely at this method I am concerned about the synchronization because it looks like it would be possible for no notify calls to occur after that wait, which would mean the wait would continue indefinitely. It would be great if someone could take a look at this as I'm not entirely sure myself what the correct solution is.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-2973) [classlib] [luni] Concerns about
synchronization in java.net.InetAddress
Posted by "Mikhail Markov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468963 ]
Mikhail Markov commented on HARMONY-2973:
-----------------------------------------
Here is the practical example of theoretical problem found by FindBugs :-) - seems like the intermittent failure of InetAddressTest (HARMONY-2962) is caused by the problem described in this JIRA.
> [classlib] [luni] Concerns about synchronization in java.net.InetAddress
> ------------------------------------------------------------------------
>
> Key: HARMONY-2973
> URL: https://issues.apache.org/jira/browse/HARMONY-2973
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Sian January
> Attachments: H-2973.patch, H-2973upd.patch
>
>
> FindBugs raised two concerns about synchronization in InetAddress.isReachableByMultiThread(...) - an unconditional wait on line 888, and also the fact that the same wait is not in a loop. Looking more closely at this method I am concerned about the synchronization because it looks like it would be possible for no notify calls to occur after that wait, which would mean the wait would continue indefinitely. It would be great if someone could take a look at this as I'm not entirely sure myself what the correct solution is.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (HARMONY-2973) [classlib] [luni] Concerns about
synchronization in java.net.InetAddress
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Ellison closed HARMONY-2973.
--------------------------------
Verified by Sian.
> [classlib] [luni] Concerns about synchronization in java.net.InetAddress
> ------------------------------------------------------------------------
>
> Key: HARMONY-2973
> URL: https://issues.apache.org/jira/browse/HARMONY-2973
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Sian January
> Assigned To: Tim Ellison
> Attachments: H-2973.patch, H-2973upd.patch
>
>
> FindBugs raised two concerns about synchronization in InetAddress.isReachableByMultiThread(...) - an unconditional wait on line 888, and also the fact that the same wait is not in a loop. Looking more closely at this method I am concerned about the synchronization because it looks like it would be possible for no notify calls to occur after that wait, which would mean the wait would continue indefinitely. It would be great if someone could take a look at this as I'm not entirely sure myself what the correct solution is.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HARMONY-2973) [classlib] [luni] Concerns about
synchronization in java.net.InetAddress
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Ellison reassigned HARMONY-2973:
------------------------------------
Assignee: Tim Ellison
> [classlib] [luni] Concerns about synchronization in java.net.InetAddress
> ------------------------------------------------------------------------
>
> Key: HARMONY-2973
> URL: https://issues.apache.org/jira/browse/HARMONY-2973
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Sian January
> Assigned To: Tim Ellison
> Attachments: H-2973.patch, H-2973upd.patch
>
>
> FindBugs raised two concerns about synchronization in InetAddress.isReachableByMultiThread(...) - an unconditional wait on line 888, and also the fact that the same wait is not in a loop. Looking more closely at this method I am concerned about the synchronization because it looks like it would be possible for no notify calls to occur after that wait, which would mean the wait would continue indefinitely. It would be great if someone could take a look at this as I'm not entirely sure myself what the correct solution is.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-2973) [classlib] [luni] Concerns about
synchronization in java.net.InetAddress
Posted by "Mikhail Markov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikhail Markov updated HARMONY-2973:
------------------------------------
Attachment: H-2973upd.patch
> [classlib] [luni] Concerns about synchronization in java.net.InetAddress
> ------------------------------------------------------------------------
>
> Key: HARMONY-2973
> URL: https://issues.apache.org/jira/browse/HARMONY-2973
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Sian January
> Attachments: H-2973.patch, H-2973upd.patch
>
>
> FindBugs raised two concerns about synchronization in InetAddress.isReachableByMultiThread(...) - an unconditional wait on line 888, and also the fact that the same wait is not in a loop. Looking more closely at this method I am concerned about the synchronization because it looks like it would be possible for no notify calls to occur after that wait, which would mean the wait would continue indefinitely. It would be great if someone could take a look at this as I'm not entirely sure myself what the correct solution is.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-2973) [classlib] [luni] Concerns about
synchronization in java.net.InetAddress
Posted by "Mikhail Markov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikhail Markov updated HARMONY-2973:
------------------------------------
Attachment: H-2973.patch
> [classlib] [luni] Concerns about synchronization in java.net.InetAddress
> ------------------------------------------------------------------------
>
> Key: HARMONY-2973
> URL: https://issues.apache.org/jira/browse/HARMONY-2973
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Sian January
> Attachments: H-2973.patch
>
>
> FindBugs raised two concerns about synchronization in InetAddress.isReachableByMultiThread(...) - an unconditional wait on line 888, and also the fact that the same wait is not in a loop. Looking more closely at this method I am concerned about the synchronization because it looks like it would be possible for no notify calls to occur after that wait, which would mean the wait would continue indefinitely. It would be great if someone could take a look at this as I'm not entirely sure myself what the correct solution is.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-2973) [classlib] [luni] Concerns about
synchronization in java.net.InetAddress
Posted by "Mikhail Markov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465077 ]
Mikhail Markov commented on HARMONY-2973:
-----------------------------------------
I've just posted a patch for this issue - could you please take a look? Thanks!
> [classlib] [luni] Concerns about synchronization in java.net.InetAddress
> ------------------------------------------------------------------------
>
> Key: HARMONY-2973
> URL: https://issues.apache.org/jira/browse/HARMONY-2973
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Sian January
> Attachments: H-2973.patch
>
>
> FindBugs raised two concerns about synchronization in InetAddress.isReachableByMultiThread(...) - an unconditional wait on line 888, and also the fact that the same wait is not in a loop. Looking more closely at this method I am concerned about the synchronization because it looks like it would be possible for no notify calls to occur after that wait, which would mean the wait would continue indefinitely. It would be great if someone could take a look at this as I'm not entirely sure myself what the correct solution is.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-2973) [classlib] [luni] Concerns about
synchronization in java.net.InetAddress
Posted by "Sian January (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470613 ]
Sian January commented on HARMONY-2973:
---------------------------------------
Thanks Tim - that looks right to me.
> [classlib] [luni] Concerns about synchronization in java.net.InetAddress
> ------------------------------------------------------------------------
>
> Key: HARMONY-2973
> URL: https://issues.apache.org/jira/browse/HARMONY-2973
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Sian January
> Assigned To: Tim Ellison
> Attachments: H-2973.patch, H-2973upd.patch
>
>
> FindBugs raised two concerns about synchronization in InetAddress.isReachableByMultiThread(...) - an unconditional wait on line 888, and also the fact that the same wait is not in a loop. Looking more closely at this method I am concerned about the synchronization because it looks like it would be possible for no notify calls to occur after that wait, which would mean the wait would continue indefinitely. It would be great if someone could take a look at this as I'm not entirely sure myself what the correct solution is.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-2973) [classlib] [luni] Concerns about
synchronization in java.net.InetAddress
Posted by "Mikhail Markov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465740 ]
Mikhail Markov commented on HARMONY-2973:
-----------------------------------------
You've convinced me :-) - 1000 ms for wait will be fine.
I'll repost modified patch for easier integration. Could you please set "patch available" tag after that?
As for '&&' vs '||': the cycle should be exited if 'reached' became true or if 'addrCount' became 0, inverting this statement we'll get the statement for while loop: go to next iteration while 'reached' != true && 'addrCount' != 0. So '&&' seems correct to me.
(Another reason that the statement is correct is testing: if "&&" was incorrect then all the tests using this method failed due to ant timeout as they iterate indefinitely, because reached could not be true at the same time when addrCount = 0 :-))
> [classlib] [luni] Concerns about synchronization in java.net.InetAddress
> ------------------------------------------------------------------------
>
> Key: HARMONY-2973
> URL: https://issues.apache.org/jira/browse/HARMONY-2973
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Sian January
> Attachments: H-2973.patch
>
>
> FindBugs raised two concerns about synchronization in InetAddress.isReachableByMultiThread(...) - an unconditional wait on line 888, and also the fact that the same wait is not in a loop. Looking more closely at this method I am concerned about the synchronization because it looks like it would be possible for no notify calls to occur after that wait, which would mean the wait would continue indefinitely. It would be great if someone could take a look at this as I'm not entirely sure myself what the correct solution is.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira