You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Yu Lin (JIRA)" <ji...@apache.org> on 2012/07/03 00:28:57 UTC
[jira] [Created] (DIRMINA-897) atomicity violation bugs because of
misusing concurrent collections
Yu Lin created DIRMINA-897:
------------------------------
Summary: atomicity violation bugs because of misusing concurrent collections
Key: DIRMINA-897
URL: https://issues.apache.org/jira/browse/DIRMINA-897
Project: MINA
Issue Type: Bug
Affects Versions: 2.0.4
Reporter: Yu Lin
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) {
...
L165 threadIds.put(cls, new AtomicInteger(newThreadId));
L166 } 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DIRMINA-897) atomicity violation bugs because of
misusing concurrent collections
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny resolved DIRMINA-897.
---------------------------------------
Resolution: Fixed
Patch applied : http://svn.apache.org/viewvc?rev=1359085&view=rev
Many thanks !
> atomicity violation bugs because of misusing concurrent collections
> -------------------------------------------------------------------
>
> Key: DIRMINA-897
> URL: https://issues.apache.org/jira/browse/DIRMINA-897
> Project: MINA
> Issue Type: Bug
> Affects Versions: 2.0.4
> Reporter: Yu Lin
> Labels: patch
> Attachments: mina-2.0.4.patch
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> 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) {
> ...
> L165 threadIds.put(cls, new AtomicInteger(newThreadId));
> L166 } 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRMINA-897) atomicity violation bugs because
of misusing concurrent collections
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13405884#comment-13405884 ]
Emmanuel Lecharny commented on DIRMINA-897:
-------------------------------------------
Thanks for the patch !
This part of the code has been modified a while ago, and we replaced the HashMap with ConcurrentHashMap without checking the context they were used.
I'll apply the patche.
> atomicity violation bugs because of misusing concurrent collections
> -------------------------------------------------------------------
>
> Key: DIRMINA-897
> URL: https://issues.apache.org/jira/browse/DIRMINA-897
> Project: MINA
> Issue Type: Bug
> Affects Versions: 2.0.4
> Reporter: Yu Lin
> Labels: patch
> Attachments: mina-2.0.4.patch
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> 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) {
> ...
> L165 threadIds.put(cls, new AtomicInteger(newThreadId));
> L166 } 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DIRMINA-897) atomicity violation bugs because of
misusing concurrent collections
Posted by "Yu Lin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Yu Lin updated DIRMINA-897:
---------------------------
Attachment: (was: mina-2.0.4.patch)
> atomicity violation bugs because of misusing concurrent collections
> -------------------------------------------------------------------
>
> Key: DIRMINA-897
> URL: https://issues.apache.org/jira/browse/DIRMINA-897
> Project: MINA
> Issue Type: Bug
> Affects Versions: 2.0.4
> Reporter: Yu Lin
> Labels: patch
> Attachments: mina-2.0.4.patch
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> 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) {
> ...
> L165 threadIds.put(cls, new AtomicInteger(newThreadId));
> L166 } 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DIRMINA-897) atomicity violation bugs because of
misusing concurrent collections
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRMINA-897:
--------------------------------------
Fix Version/s: 2.0.5
> atomicity violation bugs because of misusing concurrent collections
> -------------------------------------------------------------------
>
> Key: DIRMINA-897
> URL: https://issues.apache.org/jira/browse/DIRMINA-897
> Project: MINA
> Issue Type: Bug
> Affects Versions: 2.0.4
> Reporter: Yu Lin
> Labels: patch
> Fix For: 2.0.5
>
> Attachments: mina-2.0.4.patch
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> 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) {
> ...
> L165 threadIds.put(cls, new AtomicInteger(newThreadId));
> L166 } 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DIRMINA-897) atomicity violation bugs because of
misusing concurrent collections
Posted by "Yu Lin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Yu Lin updated DIRMINA-897:
---------------------------
Attachment: mina-2.0.4.patch
> atomicity violation bugs because of misusing concurrent collections
> -------------------------------------------------------------------
>
> Key: DIRMINA-897
> URL: https://issues.apache.org/jira/browse/DIRMINA-897
> Project: MINA
> Issue Type: Bug
> Affects Versions: 2.0.4
> Reporter: Yu Lin
> Labels: patch
> Attachments: mina-2.0.4.patch
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> 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) {
> ...
> L165 threadIds.put(cls, new AtomicInteger(newThreadId));
> L166 } 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DIRMINA-897) atomicity violation bugs because of
misusing concurrent collections
Posted by "Yu Lin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Yu Lin updated DIRMINA-897:
---------------------------
Attachment: mina-2.0.4.patch
This is a patch that may fix the atomicity violation problem I mentioned.
> atomicity violation bugs because of misusing concurrent collections
> -------------------------------------------------------------------
>
> Key: DIRMINA-897
> URL: https://issues.apache.org/jira/browse/DIRMINA-897
> Project: MINA
> Issue Type: Bug
> Affects Versions: 2.0.4
> Reporter: Yu Lin
> Labels: patch
> Attachments: mina-2.0.4.patch
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> 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) {
> ...
> L165 threadIds.put(cls, new AtomicInteger(newThreadId));
> L166 } 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira