Major Description
My name is Yu Lin. I'm a Ph.D. student in the CS department at
UIUC. I'm currently doing research on mining Java concurrent library
misusages. I found some misusages of ConcurrentHashMap in Mina
2.0.4, which may result in potential atomicity violation bugs or harm
the performance.
The code below is a snapshot of the code in file
mina-core/src/main/java/org/apache/mina/core/polling/AbstractPollingIoProcessor.java
from line 156 to 170
L156 synchronized (threadIds) {
L157 // Get the current ID associated to this class' name
L158 AtomicInteger threadId = threadIds.get(cls);
L159
L160 if (threadId == null)
else
{ ... L169 }L170 }
In the code above, we may eliminate the synchronization on "threadIds"
object (line 156) by using putIfAbsent(k, v) method provided by
ConcurrentHashMap at line 165, which will improve the performance.
If we remove the the synchronized keyword without using putIfAbsent,
an atomicity violation may occur between lines <160 and 165>: Suppose
thread T1 executes line 158 and finds that the concurrent hashmap
"threadIds" doesn't contain the key "threadIds". Before thread T1
executes line 165, another thread T2 puts a pair <cls, v> in the
concurrent hashmap "threadIds". Now thread T1 resumes execution and it
will overwrite the value written by thread T2. Thus, the code no
longer preserves the "put-if-absent" semantics. However, by using
putIfAbsent, this atomicity violation can be avoided, since if T2
already puts a pair, T1 won't put again.
Similar to the above code, in
mina-core/src/main/java/org/apache/mina/core/session/DefaultIoSessionDataStructureFactory.java,
we may eliminate the synchronization on "attributes" object (line 103,
128, 144) by using putIfAbsent(k, v), remove(k, v) and replace(k, v1,
v2) method provided by the ConcurrentHashMap.
I found some similar misusages in other files:
In
mina-core/src/main/java/org/apache/mina/filter/codec/demux/DemuxingProtocolEncoder.java,
there may be an atomicity violation bug at line 207. If thread T2 put
a pair <type, value> to map "state.findEncoderCache" between lines
<160 and 207>, this value will be overwrite at line 207 by thread T1
and never be read. Again, the code no longer preserves the
"put-if-absent" semantics.
In
mina-core/src/main/java/org/apache/mina/filter/executor/DefaultIoEventSizeEstimator.java,
there may be an atomicity violation bug at line 135. If another thread
T2 puts a pair <clazz, value> to map "class2size" between lines <105 and
135>, the invocation of putIfAbsent method at line 135 by thread T1
won't put the value "answer" anymore. In this case, we should return
the value put by T2 rather than the "answer" calculated by T1.
