DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=36541>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 ------- Additional Comments From [EMAIL PROTECTED] 2005-09-08 16:43 ------- (In reply to comment #38) > (In reply to comment #37) > > If the read operations happens to bump into this moment of temporary > > inconsistacy the infinite loop can occur. > > All the entry objects will be mutated. While it may be inconsistent and might > loop for an instant (although I am not convinced this could really be the > case; > I think the trouble without any sync could only occur if there was more than > one > concurrent unsynced write, and in particular, two "remove"), the pointer value > will be corrected and the loop should exit. That's my interpretation looking > at > the code. I think I'll write a small program to test this. > You can certinaly get null returned when a valid value was added to the Map previosly as well because of the inconsistency. The hash index used to locate the first Entry is based on the hash and the length of the table (I guess we should say the chosen bucket). If the value has been added to the map. Then a call for a get occurs and a call for a write and the write makes a resize and the resize changes the location of the bucket then e could match another Entry besides the one for the correct hash then you start getting into some looping. In a test I had a get interation of 4 times occur when this happened, but considering all of the possible shifting that can occur I'm not convinced that an infinite loop could not occur. Given the bucket index algorithm and all of the possible values for a hash and a table size I don't think one can safely say it's not possible without synchronizing. If there is a way to determine that the behavior of one search for a bucket with any hash is always going to produce the same result for any size table then I think you can safely not synchronize the code.(In reply to comment #38) > (In reply to comment #37) > > If the read operations happens to bump into this moment of temporary > > inconsistacy the infinite loop can occur. > > All the entry objects will be mutated. While it may be inconsistent and might > loop for an instant (although I am not convinced this could really be the > case; > I think the trouble without any sync could only occur if there was more than > one > concurrent unsynced write, and in particular, two "remove"), the pointer value > will be corrected and the loop should exit. That's my interpretation looking > at > the code. I think I'll write a small program to test this. > You can certinaly get null returned when a valid value was added to the Map previosly as well because of the inconsistency. The hash index used to locate the first Entry is based on the hash and the length of the table (I guess we should say the chosen bucket). If the value has been added to the map. Then a call for a get occurs and a call for a write and the write makes a resize and the resize changes the location of the bucket then e could match another Entry besides the one for the correct hash then you start getting into some looping. In a test I had a get interation of 4 times occur when this happened, but considering all of the possible shifting that can occur I'm not convinced that an infinite loop could not occur. Given the bucket index algorithm and all of the possible values for a hash and a table size I don't think one can safely say it's not possible without synchronizing. If there is a way to determine that the behavior of one search for a bucket with any hash is always going to produce the same result for any size table then I think you can safely not synchronize the code. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
