Skip to end of metadata
Go to start of metadata

Rules

Risk Assessment Summary

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

LCK00-JLowProbableMedium

P4

L3

LCK01-JMediumProbableMedium

P8

L2

LCK02-JMediumProbableMedium

P8

L2

LCK04-JLowProbableMedium

P4

L3

LCK05-JLowProbableMedium

P4

L3

LCK06-JMediumProbableMedium

P8

L2

LCK07-JLowLikelyHigh

P3

L3

LCK08-JLowLikelyLow

P9

L2

LCK09-JLowProbableHigh

P2

L3

LCK10-JLowProbableMedium

P4

L3

LCK11-JLowProbableMedium

P4

L3

 


13 Comments

  1. Isn't extending Thread instead of Runnable more of a design issue?

    1. 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.

      1. Agreed. It might be a good idea to show (unexpected) interactions between synchronized methods or blocks used in Runnable with those of the Thread class (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.

  2. I think CON08 and CON09 should be merged, as was earlier. Only the consequences are different.

  3. 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.

  4. 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?

    1. Before I forget, there is a good presentation on the JMM here:

      http://cseweb.ucsd.edu/classes/fa05/cse231/Fish.pdf

      1. I like particularly the last slide - "Conclusion". It says, the JMM:

        Guarantees sequential consistency for correctly synchronized programs

        However, the best description is Trace 17.5 and the discussion below it, in the JLS.

    2. 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.

  5. 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.

  6. 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.

    1. 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.

  7. I wordsmithed the end of this section (starting with the doSomething()}} example. Comments:

    Correct synchronization entails deciding on one sequentially consistent execution order and using synchronized methods or blocks to perform all the actions sequentially.

    Does "correct synchronization" always require only one ordering? There are times when ordering can legitimately vary.
    No clue how to fix this.

    The doSomething() method is said to be atomic.

    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.