Rule 10. Concurrency (CON)

• Page:
  CON50-CPP. Do not destroy a mutex while it is locked
• Page:
  CON51-CPP. Ensure actively held locks are released on exceptional conditions
• Page:
  CON52-CPP. Prevent data races when accessing bit-fields from multiple threads
• Page:
  CON53-CPP. Avoid deadlock by locking in a predefined order
• Page:
  CON54-CPP. Wrap functions that can spuriously wake up in a loop
• Page:
  CON55-CPP. Preserve thread safety and liveness when using condition variables
• Page:
  CON56-CPP. Do not speculatively lock a non-recursive mutex that is already owned by the calling thread

• Page:
  CON40-C. Do not refer to an atomic variable twice in an expression (SEI CERT C Coding Standard)

  • review-dms
  • con
  • cwe-366
  • no-autodetect
  • ptc
  • android-unknown
  • review-jb
  • review-rcs
  • rule
  • review-ajb
  • cwe-567
  • cwe-413
  • cwe-667
  • in-cpp
• Page:
  CON33-C. Avoid race conditions when using library functions (SEI CERT C Coding Standard)

  • con
  • nptc
  • rose-possible
  • concurrency
  • android-unknown
  • rule
  • nptc-complexity
  • in-cpp
• Page:
  CON37-C. Do not call signal() in a multithreaded program (SEI CERT C Coding Standard)

  • signal
  • con
  • concurrency
  • ptc
  • android-unknown
  • rule
  • in-cpp
• Page:
  CON43-C. Do not allow data races in multithreaded code (SEI CERT C Coding Standard)

  • con
  • concurrency
  • android-unknown
  • unenforceable
  • rule
  • cwe-362
  • in-cpp
• Page:
  CON41-C. Wrap functions that can fail spuriously in a loop (SEI CERT C Coding Standard)

  • con
  • ptc
  • android-unknown
  • rule
  • in-cpp

Risk Assessment Summary