[jira] [Updated] (DIRMINA-897) atomicity violation bugs because of misusing concurrent collections

["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