harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Markov (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-2973) [classlib] [luni] Concerns about synchronization in java.net.InetAddress
Date Wed, 17 Jan 2007 18:31:30 GMT

    [ 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


View raw message