myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yu Lin (JIRA)" <>
Subject [jira] [Created] (TRINIDAD-2287) atomicity violation bugs of misusing concurrent collections
Date Wed, 11 Jul 2012 02:31:34 GMT
Yu Lin created TRINIDAD-2287:

             Summary: atomicity violation bugs of misusing concurrent collections
                 Key: TRINIDAD-2287
             Project: MyFaces Trinidad
          Issue Type: Bug
    Affects Versions: 2.0.1-core
            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 Trinidad
2.0.1, which may result in potential atomicity violation bugs or harm
the performance.

The code below is a snapshot of the code in file
from line 102 to 112

L102   PropertyKey cachedKey = _sDefaultKeyCache.get(name);

L104   if (cachedKey == null)
L105   {
L106       cachedKey = new PropertyKey(name);

L108       // we don't need putIfAbsent because we don't care about identity
L109       _sDefaultKeyCache.put(name, cachedKey);
L110   }

L112   return cachedKey;

In the code above, an atomicity violation may occur between line 105
and 109. Suppose a thread T1 executes line 102 and finds out the
concurrent hashmap does not contain the key "name". Before it gets to
execute line 109, another thread T2 puts a pair <name, v> in the
concurrent hashmap "_sDefaultKeyCache". 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.

I found some similar atomicity violations in other 17 places (I don't
list them one by one. Please see the patch).

Note that in
if we use "putIfAbsent" at line 89 and "replace" at line 115, we may
remove the synchronized keyword at line 82. Similarly, in
we may remove the synchronized by using "putIfAbsent" at line 192.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message