Rules
Risk Assessment Summary
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
| LCK00-J | Low | Probable | Medium | P4 | L3 |
| LCK01-J | Medium | Probable | Medium | P8 | L2 |
| LCK02-J | Medium | Probable | Medium | P8 | L2 |
| LCK03-J | Medium | Probable | Medium | P8 | L2 |
| LCK04-J | Low | Probable | Medium | P4 | L3 |
| LCK05-J | Low | Probable | Medium | P4 | L3 |
| LCK06-J | Medium | Probable | Medium | P8 | L2 |
| LCK07-J | Low | Likely | High | P3 | L3 |
| LCK08-J | Low | Likely | Low | P9 | L2 |
| LCK09-J | Low | Probable | High | P2 | L3 |
| LCK10-J | Low | Probable | Medium | P4 | L3 |
| LCK11-J | Low | Probable | Medium | P4 | L3 |
13 Comments
Dhruv Mohindra
Isn't extending Thread instead of Runnable more of a design issue?
David Svoboda
It 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
Agreed. 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
I think CON08 and CON09 should be merged, as was earlier. Only the consequences are different.
Dhruv Mohindra
Aren'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
This 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)
Before I forget, there is a good presentation on the JMM here:
http://cseweb.ucsd.edu/classes/fa05/cse231/Fish.pdf
Dhruv Mohindra
I 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)
I 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)
Here 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
I'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
Eventually 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
I 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.