Skip to content

Concurrency

Writing clean concurrent programs is hard . In this chapter we can know what difficulties with it's and how to handle those difficulties and writing clean concurrency.

Why Concurrency?

Concurrency is a decoupling strategy. It helps us decouple what gets done from when it gets done.

Myths and Misconceptions

  • Concurrency always improves performance.
  • Design does not change when writing concurrent programs.

    • Understanding concurrency issues is not important when working with a container such as a Web or EJB container.

    Here are a few more balanced sound bites regarding writing concurrent software:

  • Concurrency incurs some overhead, both in performance as well as writing additional code.
  • Correct concurrency is complex, even for simple problems.
  • Concurrency bugs aren’t usually repeatable, so they are often ignored as one-offs instead of the true defects they are.
  • Concurrency often requires a fundamental change in design strategy.

    • Concurrency Defense Principles

    Single Responsibility Principle :

    Keep your concurrency-related code separate from other code.

    Corollary:Limit the Scope of Data:

    Take data encapsulation to heart; severely limit the access of any data that may be shared.

    Corollary: Use Copies of Data :

    Do not share objects instead of sharing objects give a copies and then merge the results in a single thread.

    Corollary: Threads Should Be as Independent as Possible

    Attempt to partition data into independent subsets than can be operated on by independent threads, possibly in different processors.

    Know Your Library

    There are several things to consider when writing threaded code in Java 5:

  • Use the provided thread-safe collections.

    • There are several other kinds of classes added to support advanced concurrency design. Here are a few examples: ReentrantLock ,Semaphore,CountDownLatch

  • Use the executor framework for executing unrelated tasks.

    • Bound Resources,Mutual Exclusion,Starvation,Deadlock etc, are the some

  • Use nonblocking solutions when possible.
  • Several library classes are not thread safe.

    • Beware Dependencies Between Synchronized Methods

    Avoid using more than one method on a shared object.

    There will be times when you must use more than one method on a shared object. When this is the case, there are three ways to make the code correct:

  • Client-Based Locking
  • Server-Based Locking
  • Adapted Server.

    • Keep Synchronized Sections Small:

    Keep your synchronized sections as small as possible.

    Writing Correct Shut-Down Code Is Hard :

    Writing a system that is meant to stay live and run forever is different from writing something that works for awhile and then shuts down gracefully.

    So write correct shut down code.

    Testing Threaded Code

    write test cases and run them frequently, with different programatic configurations and system configurations and load. If tests ever fail, track down the failure. Don’t ignore a failure just because the tests pass on a subsequent run.

    Here are a few more fine-grained recommendations:

    • Treat spurious failures as candidate threading issues:

    Do not ignore system failures as one-offs.

    • Get your nonThreaded code working first:

    Separate both NonThreaded and threaded code and also find bugs independently.

    • Make your threaded code pluggable,Then you can run it in various configurations.

    • Make your threaded code tunable.

    • Run with more threads than processors:

    use more threads than processors

    • Run on different platforms:

    Run your threaded code on all target platforms early and often.

    • Instrument your code to try and force failures:

  • Hand-coded :

    • if we divide our system up into POJOs that know nothing of threading and classes that control the threading, it will be easier to find appropriate places to instrument the code.

  • Automated :

    • Use jiggling strategies to ferret out errors.