What are multi-threading DOs and DONTs? [closed]

Answer 1

In a multithreading environment you have to take care of synchronization so two threads doesn't clobber the state by simultaneously performing modifications. Otherwise you can have race conditions in your code (for an example see the infamous Therac-25 accident.) You also have to schedule the threads to perform various tasks. You then have to make sure that your synchronization and scheduling doesn't cause a deadlock where multiple threads will wait for each other indefinitely.

Synchronization

Something as simple as increasing a counter requires synchronization:

counter += 1;

Assume this sequence of events:

• counter is initialized to 0
• thread A retrieves counter from memory to cpu (0)
• context switch
• thread B retrieves counter from memory to cpu (0)
• thread B increases counter on cpu
• thread B writes back counter from cpu to memory (1)
• context switch
• thread A increases counter on cpu
• thread A writes back counter from cpu to memory (1)

At this point the counter is 1, but both threads did try to increase it. Access to the counter has to be synchronized by some kind of locking mechanism:

lock (myLock) {
  counter += 1;
}

Only one thread is allowed to execute the code inside the locked block. Two threads executing this code might result in this sequence of events:

• counter is initialized to 0
• thread A acquires myLock
• context switch
• thread B tries to acquire myLock but has to wait
• context switch
• thread A retrieves counter from memory to cpu (0)
• thread A increases counter on cpu
• thread A writes back counter from cpu to memory (1)
• thread A releases myLock
• context switch
• thread B acquires myLock
• thread B retrieves counter from memory to cpu (1)
• thread B increases counter on cpu
• thread B writes back counter from cpu to memory (2)
• thread B releases myLock

At this point counter is 2.

Scheduling

Scheduling is another form of synchronization and you have to you use thread synchronization mechanisms like events, semaphores, message passing etc. to start and stop threads. Here is a simplified example in C#:

AutoResetEvent taskEvent = new AutoResetEvent(false);

Task task;

// Called by the main thread.
public void StartTask(Task task) {
  this.task = task;
  // Signal the worker thread to perform the task.
  this.taskEvent.Set();
  // Return and let the task execute on another thread.
}

// Called by the worker thread.
void ThreadProc() {
  while (true) {
    // Wait for the event to become signaled.
    this.taskEvent.WaitOne();
    // Perform the task.
  }
}   

You will notice that access to this.task probably isn't synchronized correctly, that the worker thread isn't able to return results back to the main thread, and that there is no way to signal the worker thread to terminate. All this can be corrected in a more elaborate example.

Deadlock

A common example of deadlock is when you have two locks and you are not careful how you acquire them. At one point you acquire lock1 before lock2:

public void f() {
  lock (lock1) {
    lock (lock2) {
      // Do something
    }
  }
}

At another point you acquire lock2 before lock1:

public void g() {
  lock (lock2) {
    lock (lock1) {
      // Do something else
    }
  }
}

Let's see how this might deadlock:

• thread A calls f
• thread A acquires lock1
• context switch
• thread B calls g
• thread B acquires lock2
• thread B tries to acquire lock1 but has to wait
• context switch
• thread A tries to acquire lock2 but has to wait
• context switch

At this point thread A and B are waiting for each other and are deadlocked.

Answer 2

I am applying my new found knowledge of threading everywhere

[Emphasis added]

DO remember that a little knowledge is dangerous. Knowing the threading API of your platform is the easy bit. Knowing why and when you need to use synchronisation is the hard part. Reading up on "deadlocks", "race-conditions", "priority inversion" will start you in understanding why.

The details of when to use synchronisation are both simple (shared data needs synchronisation) and complex (atomic data types used in the right way don't need synchronisation, which data is really shared): a lifetime of learning and very solution specific.

Answer 3

In .Net one thing that surprised me when I started trying to get into multi-threading is that you cannot straightforwardly update the UI controls from any thread other than the thread that the UI controls were created on.

There is a way around this, which is to use the Control.Invoke method to update the control on the other thread, but it is not 100% obvious the first time around!

Answer 4

I agree with pretty much all the answers so far.

A good coding strategy is to minimise or eliminate the amount of data that is shared between threads as much as humanly possible. You can do this by:

• Using thread-static variables (although don't go overboard on this, it will eat more memory per thread, depending on your O/S).
• Packaging up all state used by each thread into a class, then guaranteeing that each thread gets exactly one state class instance to itself. Think of this as "roll your own thread-static", but with more control over the process.
• Marshalling data by value between threads instead of sharing the same data. Either make your data transfer classes immutable, or guarantee that all cross-thread calls are synchronous, or both.

Try not to have multiple threads competing for the exact same I/O "resource", whether it's a disk file, a database table, a web service call, or whatever. This will cause contention as multiple threads fight over the same resource.

Here's an extremely contrived OTT example. In a real app you would cap the number of threads to reduce scheduling overhead:

• All UI - one thread.
• Background calcs - one thread.
• Logging errors to a disk file - one thread.
• Calling a web service - one thread per unique physical host.
• Querying the database - one thread per independent group of tables that need updating.

Rather than guessing how to do divvy up the tasks, profile your app and isolate those bits that are (a) very slow, and (b) could be done asynchronously. Those are good candidates for a separate thread.

And here's what you should avoid:

• Calcs, database hits, service calls, etc - all in one thread, but spun up multiple times "to improve performance".

Answer 5

An important thing to take care of (with multiple cores and CPUs) is cache coherency.

Answer 6

-- What are some known thread issues? --

• Race conditions.
• Deadlocks.
• Livelocks.
• Thread starvation.

-- What care should be taken while using threads? --

Using multi-threading on a single-processor machine to process multiple tasks where each task takes approximately the same time isn’t always very effective.For example, you might decide to spawn ten threads within your program in order to process ten separate tasks. If each task takes approximately 1 minute to process, and you use ten threads to do this processing, you won’t have access to any of the task results for the whole 10 minutes. If instead you processed the same tasks using just a single thread, you would see the first result in 1 minute, the next result 1 minute later, and so on. If you can make use of each result without having to rely on all of the results being ready simultaneously, the single thread might be the better way of implementing the program.

If you launch a large number of threads within a process, the overhead of thread housekeeping and context switching can become significant. The processor will spend considerable time in switching between threads, and many of the threads won’t be able to make progress. In addition, a single process with a large number of threads means that threads in other processes will be scheduled less frequently and won’t receive a reasonable share of processor time.

If multiple threads have to share many of the same resources, you’re unlikely to see performance benefits from multi-threading your application. Many developers see multi-threading as some sort of magic wand that gives automatic performance benefits. Unfortunately multi-threading isn’t the magic wand that it’s sometimes perceived to be. If you’re using multi-threading for performance reasons, you should measure your application’s performance very closely in several different situations, rather than just relying on some non-existent magic.

Coordinating thread access to common data can be a big performance killer. Achieving good performance with multiple threads isn’t easy when using a coarse locking plan, because this leads to low concurrency and threads waiting for access. Alternatively, a fine-grained locking strategy increases the complexity and can also slow down performance unless you perform some sophisticated tuning.

Using multiple threads to exploit a machine with multiple processors sounds like a good idea in theory, but in practice you need to be careful. To gain any significant performance benefits, you might need to get to grips with thread balancing.

-- Please provide examples. --

For example, imagine an application that receives incoming price information from the network, aggregates and sorts that information, and then displays the results on the screen for the end user.

With a dual-core machine, it makes sense to split the task into, say, three threads. The first thread deals with storing the incoming price information, the second thread processes the prices, and the final thread handles the display of the results.

After implementing this solution, suppose you find that the price processing is by far the longest stage, so you decide to rewrite that thread’s code to improve its performance by a factor of three. Unfortunately, this performance benefit in a single thread may not be reflected across your whole application. This is because the other two threads may not be able to keep pace with the improved thread. If the user interface thread is unable to keep up with the faster flow of processed information, the other threads now have to wait around for the new bottleneck in the system.

And yes, this example comes directly from my own experience :-)