 
                            | Wiki Markup | 
|---|
| Concurrency related | 
...
| issues manifest themselves when assumptions are made about the multithreaded behavior of derived classes. An overridden synchronized method's contract may be violated if a subclass defines an implementation that is not safe for concurrent access. {mc} // This line is not necessary because thread-safe implies all kinds of synchronization Furthermore, if an overridden method makes concurrency guarantees, even if it is not itself synchronized, the subclass must adhere to those guarantees. | 
...
| {mc} The guideline [CON04-J. Synchronize using an internal private lock | 
...
Noncompliant Code Example (synchronized method)
This noncompliant code example defines a synchronized doSomething() method in a class called SynchronizedBase. 
| Code Block | ||
|---|---|---|
| 
 | ||
| class ThreadSafeBase object] recommends documenting the locking strategy in use for classes designed for inheritance. This information is useful when deciding the locking strategy of subclasses. h2. Noncompliant Code Example (synchronized method) This noncompliant code example defines a {{synchronized}} {{doSomething()}} method in class {{Base}}. {code:bgColor=#FFCCCC} class Base { public synchronized void doSomething() { // ... } } class ThreadUnsafeSubclassSub extends ThreadSafeBaseBase { public void doSomething() { // ... } } {code} | 
The base method can be safely used by many threads. However, if a subclass ThreadUnsafeSubclass overrides the method but leaves it unsynchronized, its instance cannot be safely passed to multiple threads. 
This problem is hard to notice because threads that accept instances of ThreadSafeBase also accept instances of its subclasses. Consequently, the threads may incorrectly assume that the subclasses are thread-safe.
Compliant Solution (synchronized method)
This compliant solution synchronizes the doSomething() method of the subclass. 
| Code Block | ||
|---|---|---|
| 
 | ||
| class ThreadSafeBase The {{doSomething()}} method of class {{Base}} can be safely used by multiple threads. However, if a subclass {{Sub}} overrides the method but leaves it unsynchronized, its instance cannot be safely used by multiple threads. This problem is hard to notice because threads that accept instances of {{Base}} also accept instances of its subclasses. Consequently, the threads may incorrectly assume that the subclasses are thread-safe. h2. Compliant Solution (synchronized method) This compliant solution synchronizes the {{doSomething()}} method of the subclass. {code:bgColor=#ccccff} class Base { public synchronized void doSomething() { // ... } } class ThreadSafeSubclassSub extends ThreadSafeBaseBase { public synchronized void doSomething() { // ... } } {code} This compliant solution does not violate [CON04-J. Synchronize using an internal private lock object] because the accessibility of the class is package-private which is allowable when untrusted code cannot infiltrate the package. h2. | 
...
| Noncompliant Code Example (private lock) | 
...
| This noncompliant code example defines a {{doSomething()}} method in | 
...
| class {{Base}} that uses an internal private lock, in accordance with [CON04-J. Synchronize using an internal private lock object]. | 
...
| {code | ||
| :bgColor | =#FFCCCC | } public class ThreadSafeBaseBase { private final Object lock = new Object(); public void doSomething() { synchronized (lock) { // ... } } } class ThreadUnsafeSubclassSub extends ThreadSafeBaseBase { public void doSomething() { // ... } } | 
The base method can be safely used by many threads. However, if a subclass ThreadUnsafeSubclass overrides the method but provides no concurrency guarantees, its instance cannot be safely passed to multiple threads. 
Compliant Solution (private lock)
This compliant solution synchronizes the doSomething() method of the subclass. 
| Code Block | ||
|---|---|---|
| 
 | ||
| class ThreadSafeBase{code} The {{doSomething()}} method of class {{Sub}} cannot be safely used by multiple threads because it is not thread-safe. h2. Compliant Solution (private lock) This compliant solution synchronizes the {{doSomething()}} method of the subclass. {code:bgColor=#ccccff} public class Base { private final Object lock = new Object(); public void doSomething() { synchronized (lock) { // ... } } } class ThreadSafeSubclassSub extends ThreadSafeBaseBase { private final Object lock = new Object(); public void doSomething() { synchronized (lock) { // ... } } } {code} Note that the | 
...
| {{Base.lock | 
...
| }} and {{Sub.lock}} objects are distinct | 
...
| and inaccessible from each others' classes. Consequently, {{Sub}} can provide thread-safety | 
...
Risk Assessment
Failure to provide synchronization in overriding methods can result in unexpected behavior.
| Rule | Severity | Likelihood | Remediation Cost | Priority | Level | 
|---|---|---|---|---|---|
| CON10- J | low | probable | medium | P4 | L3 | 
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
...
| guarantees independent of {{Base}}. h2. Exceptions *EX1*: If the class {{Base}} performs a single operation, such as calling the corresponding super class method, or throwing an exception, it need not be synchronized. {code:bgColor=#ccccff} // ... class Sub extends Base { public void doSomething() { super.doSomething(); } } {code} *EX2*: If the class {{Base}} calls multiple thread-safe APIs that are independent of each other, that is, they do not operate on the same shared data, this guideline may be violated. {code:bgColor=#ccccff} // ... class Sub extends Base { public void doSomething() { try { super.doSomething(); } finally() { logger.log(Level.FINE, "Did something"); // Independent of previous statements } } } {code} h2. Risk Assessment Overriding thread-safe methods with thread-unsafe methods can result in unexpected behavior. || Rule || Severity || Likelihood || Remediation Cost || Priority || Level || | CON10- J | low | probable | medium | {color:green}{*}P4{*}{color} | {color:green}{*}L3{*}{color} | h3. Automated Detection TODO h3. Related Vulnerabilities Search for vulnerabilities resulting from the violation of this rule on the [CERT website|https://www.kb.cert.org/vulnotes/bymetric?searchview&query=FIELD+KEYWORDS+contains+CON06-J]. h2. References \[[API 06|AA. Java References#API 06]\] \[[SDN 08|AA. Java References#SDN 08]\] Sun bug database, [Bug ID 4294756|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4294756] | 
...
| ---- [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_left.png!|VOID CON09-J. Do not invoke alien methods that rely on invariants protected by the same lock | 
...
| object]      [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_up.png!|11. Concurrency (CON)]      [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_right.png!|CON11-J. Do not assume that declaring an object volatile guarantees visibility of its members] |