Rules
Risk Assessment Summary
Rule | Severity | Likelihood | Detectable | Repairable | Priority | Level |
|---|---|---|---|---|---|---|
| LCK00-J | Low | Probable | No | No | P2 | L3 |
| LCK01-J | Medium | Probable | Yes | No | P8 | L2 |
| LCK02-J | Medium | Probable | Yes | No | P8 | L2 |
| LCK03-J | Medium | Probable | Yes | No | P8 | L2 |
| LCK04-J | Low | Probable | Yes | No | P4 | L3 |
| LCK05-J | Low | Probable | No | No | P2 | L3 |
| LCK06-J | Medium | Probable | Yes | No | P8 | L2 |
| LCK07-J | Low | Likely | No | No | P3 | L3 |
| LCK08-J | Low | Likely | Yes | Yes | P9 | L2 |
| LCK09-J | Low | Probable | No | No | P2 | L3 |
| LCK10-J | Low | Probable | Yes | No | P4 | L3 |
| LCK11-J | Low | Probable | No | No | P2 | L3 |
13 Comments
Dhruv Mohindra
Apr 02, 2009Isn't extending Thread instead of Runnable more of a design issue?
David Svoboda
Apr 02, 2009It is. But it is a common error which makes multithreaded code harder to read. It was also a common coding mistake by yours truly. Finally, I do think some doc (prob the Java Tutorial) recommends against it.
Dhruv Mohindra
Apr 25, 2011Agreed. It might be a good idea to show (unexpected) interactions between synchronized methods or blocks used in Runnable with those of the
Threadclass (Doug Lea). Incidentally, a couple of my sources: [Darwin 04] and [Daconta 03] violate this recommendation. Consequently, so do THI05-J. Do not use Thread.stop() to terminate threads and FIO10-J. Do not let Runtime.exec() fail or block indefinitely. I doubt there are any security breaches here but I can imagine something could very well go wrong if there is some misuse.Dhruv Mohindra
Dec 31, 2009I think CON08 and CON09 should be merged, as was earlier. Only the consequences are different.
Dhruv Mohindra
Jan 10, 2010Aren't we missing sequential consistency? Happens-before guarantees are not enough for proper visibility because out-of-thin-air results are permissible. This cannot be overlooked.
Dhruv Mohindra
Jan 10, 2010This is a good way to specify what sequential consistency implies but now we might need to define "total order" and "process order". Can we use program order instead, as defined?
Robert Seacord (Manager)
Jan 10, 2010Before I forget, there is a good presentation on the JMM here:
http://cseweb.ucsd.edu/classes/fa05/cse231/Fish.pdf
Dhruv Mohindra
Jan 10, 2010I like particularly the last slide - "Conclusion". It says, the JMM:
However, the best description is Trace 17.5 and the discussion below it, in the JLS.
Robert Seacord (Manager)
Jan 10, 2010I tried rewriting to harmonize the "orderings". I think we have to review this some more to make sure it is consistent with the JLS and/or with common usage.
Robert Seacord (Manager)
Jan 21, 2010Here are a few recommendations from Goetz:
1. Update related state variables in a single atomic operation.
2. All accesses to each mutable state variable must be performed with the same lock held.
3. Every shared, mutable variable should be guarded by exactly one lock.
4. For every invariant that involves more than one variable, all the variables invovled must be guarded by the same lock.
Robert Seacord
Feb 17, 2010I've noticed the exceptions are using ID's of the form:
CON14:EX1:
While in the other standards we use:
PRE00-EX1:
for example PRE00-C. Prefer inline or static functions to function-like macros
The last ':' is not part of the ID, just punctuation, but the first ":" in the ID is confusing. I think we should just use the hyphenated form, like in the other coding standards.
Dhruv Mohindra
Feb 17, 2010Eventually we will. The idea was to separate the guideline number from exception number because the numbering/order is likely to change again and then we have to fix everything manually.
David Svoboda
May 14, 2010I wordsmithed the end of this section (starting with the doSomething()}} example. Comments:
Does "correct synchronization" always require only one ordering? There are times when ordering can legitimately vary.
No clue how to fix this.
It is not atomic, other threads can work with those variables simultaneously. Locking the object monitor lock provides a mechanism for other threads to avoid data races, but only if they also use it. Dunno how to fix it, so I took this out.