Sometime we really need to choose a multi-threaded design, because single-threading will block the UI or block another thread.

But sometimes using multiple threads is just one of the choices, for example, you may able to replace multi-threading with timer. In that situation, you may want to avoid the effort of investigating the performance risk of using timer and directly go to the multi-threaded design. But as we know, threading has a lot of drawbacks:

  1. Sync issue.
  2. Debugging is tough for sync issue.
  3. Deadlock issue.

The #1 can always resolved by adding locks, and #3 is the hardest to resolve, it may need design level changes. So let's focus on when will be safe to choose multi-threaded design without having deadlock issues.

I use the Following rules to judge it is safe or not:

  • The component only has input data and entry function call interaction.
  • Or the component only has output data and exit function call interaction.
  • Or you have entry and exit data or function call, but you can make sure all the data that goes in can be handled asynchronously. (I cannot think out of case, because you almost always need to syncronized to push the data into an queue.)

Does that make sense to you, any thought is welcome.

closed as too broad by Robert Harvey, user40980, gnat, GlenH7, Kilian Foth Sep 25 '13 at 10:43

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

up vote 0 down vote accepted

There are two sources of deadlock to consider.

There is designed deadlock, where the actual architectural design is the cause of the deadlock. To solve this, you need to understand the mechanism that leads up to the deadlock, and redesign the architecture. Common issues include having two resources that need exclusive access and different sections of code obtaining the locks for these resources in a different order.

The second source of deadlock is caused by not releasing locks In this scenario, its not the design but the implementation that is at fault. The implementation grabs exclusive access, but when it no longer needs the exclusive access it fails to release the locking mechanism. These bugs are not always easy to identify the source because the bug is not always where the code is blocked.

There are two good strategies to adopt with dealing with multi threaded applications.

  1. Have a really clearly designed architecture. This will allow you to identify and avoid designed in deadlock.
  2. Use a logging package to log application flow and have a trace logging level that logs locks and unlocks to the log.

With both of these in place you have the evidence of what has happened in the run up to a deadlock occurring.

This is a large topic. The general idea is to not share mutable state among threads. If one thread can change a value another thread is using, or depends on, you have issues that must be handled.

Your first rule is incomplete. Is the data shared? You might need atomic semantics here. For example an increment is (indirectly) a goes-in function.

The second may be sufficient, it may not be. It depends on what data it returns, on what uses the data and what other data depends on the data returned so I think there is still the possibility of deadlock here.

Not the answer you're looking for? Browse other questions tagged or ask your own question.