...
Consider, for example, two threads that call toggle(). The expected effect of toggling flag twice is that it is restored to its original value. However, the following scenario leaves flag in the incorrect state:
Time | flag= | Thread | Action |
|---|---|---|---|
1 | true | t1 | Reads the current value of |
2 | true | t2 | Reads the current value of |
3 | true | t1 | Toggles the temporary variable to false |
4 | true | t2 | Toggles the temporary variable to false |
5 | false | t1 | Writes the temporary variable's value to |
6 | false | t2 | Writes the temporary variable's value to |
As a result, the effect of the call by t2 is not reflected in flag; the program behaves as if toggle() was called only once, not twice.
...
This solution guards reads and writes to the flag field with a lock on the instance, that is, this. Furthermore, synchronization ensures that changes are visible to all threads. Now, only two execution orders are possible, one of which is shown in the following scenario:
Time | flag= | Thread | Action |
|---|---|---|---|
1 | true | t1 | Reads the current value of |
2 | true | t1 | Toggles the temporary variable to false |
3 | false | t1 | Writes the temporary variable's value to |
4 | false | t2 | Reads the current value of |
5 | false | t2 | Toggles the temporary variable to true |
6 | true | t2 | Writes the temporary variable's value to |
The second execution order involves the same operations, but t2 starts and finishes before t1.
Compliance with LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code can reduce the likelihood of misuse by ensuring that untrusted callers cannot access the lock object.
...
When operations on shared variables are not atomic, unexpected results can be produced. For example, information can be disclosed inadvertently because one user can receive information about other users.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
VNA02-J | Medium | Probable | Medium | P8 | L2 |
Automated Detection
Some available static analysis tools can detect the instances of non-atomic update of a concurrently shared value. The result of the update is determined by the interleaving of thread execution. These tools can detect the instances where thread-shared data is accessed without holding an appropriate lock, possibly causing a race condition.
| Tool | Version | Checker | Description |
|---|---|---|---|
| CodeSonar | 4.2 | FB.MT_CORRECTNESS.IS2_INCONSISTENT_SYNC FB.MT_CORRECTNESS.IS_FIELD_NOT_GUARDED FB.MT_CORRECTNESS.STCAL_INVOKE_ON_STATIC_CALENDAR_INSTANCE FB.MT_CORRECTNESS.STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE FB.MT_CORRECTNESS.STCAL_STATIC_CALENDAR_INSTANCE FB.MT_CORRECTNESS.STCAL_STATIC_SIMPLE_DATE_FORMAT_INSTANCE | Inconsistent synchronization Field not guarded against concurrent access Call to static Calendar Call to static DateFormat Static Calendar field Static DateFormat |
| Coverity | 7.5 | GUARDED_BY_VIOLATION | Implemented |
| Parasoft Jtest |
|
|
| TRS.SSUG |
TRS.MRAV |
| Make the get method for a field synchronized if the set method is synchronized Access related Atomic variables in a synchronized block | |||||||||
| ThreadSafe |
| CCE_SL_INCONSISTENT | Implemented |
...
Related Guidelines
CWE-366, Race Condition within a Thread |
Bibliography
[API 2014] | |
Item 66, "Synchronize Access to Shared Mutable Iata" | |
Section 2.3, "Locking" | |
[JLS 2015] | Chapter 17, "Threads and Locks" |
[Lea 2000] | Section 2.1.1.1, "Objects and Locks" |
...
...