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

Answer 1

Don't be fooled into thinking you understand the difficulties of concurrency until you've split your head into a real project.

All the examples of deadlocks, livelocks, synchronization, etc, seem simple, and they are. But they will mislead you, because the "difficulty" in implementing concurrency that everyone is talking about is when it is used in a real project, where you don't control everything.

Answer 2

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.

Answer 3

DO think about how you will test your code and set aside plenty of time for this. Unit tests become more complicated. You may not be able to manually test your code - at least not reliably.

DO think about thread lifetime and how threads will exit. Don't kill threads. Provide a mechanism so that they exit gracefully.

DO add some kind of debug logging to your code - so that you can see that your threads are behaving correctly both in development and in production when things break down.

DO use a good library for handling threading rather than rolling your own solution (if you can). E.g. java.util.concurrency

DON'T assume a shared resource is thread safe.

DON'T DO IT. E.g. use an application container that can take care of threading issues for you. Use messaging.

Answer 4

Don't start new threads unless you really need to. Starting threads is not cheap and for short running tasks starting the thread may actually take more time than executing the task itself. If you're on .NET take a look at the built in thread pool, which is useful in a lot of (but not all) cases. By reusing the threads the cost of starting threads is reduced.

EDIT: A few notes on creating threads vs. using thread pool (.NET specific)

Generally try to use the thread pool. Exceptions:

• Long running CPU bound tasks and blocking tasks are not ideal run on the thread pool cause they will force the pool to create additional threads.
• All thread pool threads are background threads, so if you need your thread to be foreground, you have to start it yourself.
• If you need a thread with different priority.
• If your thread needs more (or less) than the standard 1 MB stack space.
• If you need to be able to control the life time of the thread.
• If you need different behavior for creating threads than that offered by the thread pool (e.g. the pool will throttle creating of new threads, which may or may not be what you want).

There are probably more exceptions and I am not claiming that this is the definitive answer. It is just what I could think of atm.

Answer 5

a) Always make only 1 thread responsible for a resource's lifetime. That way thread A won't delete a resource thread B needs - if B has ownership of the resource

b) Expect the unexpected

Answer 6

While your initial differences in sums of numbers are, as several respondents have pointed out, likely to be the result of lack of synchronisation, if you get deeper into the topic, be aware that, in general, you will not be able to reproduce exactly the numeric results you get on a serial program with those from a parallel version of the same program. Floating-point arithmetic is not strictly commutative, associative, or distributive; heck, it's not even closed.

And I'd beg to differ with what, I think, is the majority opinion here. If you are writing multi-threaded programs for a desktop with one or more multi-core CPUs, then you are working on a shared-memory computer and should tackle shared-memory programming. Java has all the features to do this.

Without knowing a lot more about the type of problem you are tackling, I'd hesitate to write that 'you should do this' or 'you should not do that'.