When is multi-threading not a good idea? [closed]

Answer 1

In priciple everytime there is no overhead for the caller to wait in a queue.

Answer 2

A common source of threading issues is the usual approaches employed to synchronize data. Having threads share state and then implement locking at all the appropriate places is a major source of complexity for both design and debugging. Getting the locking right to balance stability, performance, and scalability is always a hard problem to solve. Even the most experienced experts get it wrong frequently. Alternative techniques to deal with threading can alleviate much of this complexity. The Clojure programming language implements several interesting techniques for dealing with concurrency.

Answer 3

Multi-threading is a bad idea if:

• Several threads access and update the same resource (set a variable, write to a file), and you don't understand thread safety.

• Several threads interact with each other and you don't understand mutexes and similar thread-management tools.

• Your program uses static variables (threads typically share them by default).

• You haven't debugged concurrency issues.

Answer 4

Multi-threading is scalable, and will allow your UI to maintain its responsivness while doing very complicated things in the background. I don't understand where other responses are acquiring their information on multi-threading.

When you shouldn't multi-thread is a mis-leading question to your problem. Your problem is this: Why did multi-threading my application cause serial / ethernet communications to fail?

The answer to that question will depend on the implementation, which should be discussed in another question. I know for a fact that you can have both ethernet and serial communications happening in a multi-threaded application at the same time as numerous other tasks without causing any data loss.

The one reason to not use multi-threading is:

1. There is one task, and no user interface with which the task will interfere.

The reasons to use mutli-threading are:

1. Provides superior responsiveness to the user
2. Performs multiple tasks at the same time to decrease overall execution time
3. Uses more of the current multi-core CPUs, and multi-multi-cores of the future.

There are three basic methods of multi-threaded programming that make thread safety implemented with ease - you only need to use one for success:

1. Thread Safe Data types passed between threads.
2. Thread Safe Methods in the threaded object to modify data passed between.
3. PostMessage capabilities to communicate between threads.

Answer 5

A couple more possible reasons to use threads:

1. Your platform lacks asynchronous I/O operations, e.g. Windows ME (No completion ports or overlapped I/O, a pain when porting XP applications that use them.) Java 1.3 and earlier.
2. A third-party library function that can hang, e.g. if a remote server is down, and the library provides no way to cancel the operation and you can't modify it.

Keeping a GUI responsive during intensive processing doesn't always require additional threads. A single callback function is usually sufficient.

If none of the above apply and I still want parallelism for some reason, I prefer to launch an independent process if possible.

Answer 6

Multithreading is bad except in the single case where it is good. This case is

1. The work is CPU Bound, or parts of it is CPU Bound
2. The work is parallelisable.

If either or both of these conditions are missing, multithreading is not going to be a winning strategy.

If the work is not CPU bound, then you are waiting not on threads to finish work, but rather for some external event, such as network activity, for the process to complete its work. Using threads, there is the additional cost of context switches between threads, The cost of synchronization (mutexes, etc), and the irregularity of thread preemption. The alternative in most common use is asynchronous IO, in which a single thread listens to several io ports, and acts on whichever happens to be ready now, one at a time. If by some chance these slow channels all happen to become ready at the same time, It might seem like you will experience a slow-down, but in practice this is rarely true. The cost of handling each port individually is often comparable or better than the cost of synchronizing state on multiple threads as each channel is emptied.

Many tasks may be compute bound, but still not practical to use a multithreaded approach because the process must synchronise on the entire state. Such a program cannot benefit from multithreading because no work can be performed concurrently. Fortunately, most programs that require enormous amounts of CPU can be parallelized to some level.