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

Question

I am applying my new found knowledge of threading everywhere and getting lots of surprises

Example:

I used threads to add numbers in an array. And outcome was different every time. The problem was that all of my threads were updating the same variable and were not synchronized.

• What are some known thread issues?
• What care should be taken while using threads?
• What are good multithreading resources.
• Please provide examples.

sidenote:
(I renamed my program thread_add.java to thread_random_number_generator.java:-)

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

There are two kinds of people that do not use multi threading.

1) Those that do not understand the concept and have no clue how to program it. 2) Those that completely understand the concept and know how difficult it is to get it right.

Answer 3

I'd make a very blatant statement:

DON'T use shared memory.

DO use message passing.

As a general advice, try to limit the amount of shared state and prefer more event-driven architectures.