> From: Mark Thomas [mailto:ma...@apache.org] > Subject: Re: svn commit: r1703194 - > /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
> The odds of a data race here are slim (to non-existent) That's definitely true; the questions arising here are more theoretical than practical for this particular instance. However, they may be applicable to other areas. > The use of volatile ensures that the current thread updating the > field sees the value set by the previous thread to update it. Ok, I misunderstood the situation - didn't realize that something else is preventing actual concurrent use. But since the whole issue is based on multiple threads calling this method, what prevents the concurrency? (I've seen threads on Linux interrupted and held up for seconds when unrelated page table management is underway, allowing some very unexpected data sharing.) If the multiple threads that arrive here sequentially are ordered by some other mechanism (e.g., synchronization, context switch, termination), the volatile still isn't needed. > Some further comments in the code t explain the above are probably > called for. That would indeed help. > > I am concerned that the iterator in the for loop of backgroundProcess() may > > lose its > > validity if another thread updates the map > The Javadoc for ConcurrentHashMap says this usage is safe. The only statement I can find in the Javadoc is this: "Similarly, Iterators, Spliterators and Enumerations return elements reflecting the state of the hash table at some point at or since the creation of the iterator/enumeration. They do not throw ConcurrentModificationException." Not quite the reassurance I'm looking for that an iterator will actually be useful (i.e., find all remaining entries) after the map has been mutated and possibly reorganized by another thread. This is one spot where the C++ spec is clearer (rather surprisingly). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
