Question

I’ve read that threads are very problematic. What alternatives are available? Something that handles blocking and stuff automatically?

A lot of people recommend the background worker, but I’ve no idea why.

Anyone care to explain “easy” alternatives? The user will be able to select the number of threads to use (depending on their speed needs and computer power).

Any ideas?

Answer 1

To summarize the problems with threads:

• if threads share memory, you can get
  race conditions
• if you avoid races by liberally using locks, you
  can get deadlocks (see the dining philosophers problem)

An example of a race: suppose two threads share access to some memory where a number is stored. Thread 1 reads from the memory address and stores it in a CPU register. Thread 2 does the same. Now thread 1 increments the number and writes it back to memory. Thread 2 then does the same. End result: the number was only incremented by 1, while both threads tried to increment it. The outcome of such interactions depend on timing. Worse, your code may seem to work bug-free but once in a blue moon the timing is wrong and bad things happen.

To avoid these problems, the answer is simple: avoid sharing writable memory. Instead, use message passing to communicate between threads. An extreme example is to put the threads in separate processes and communicate via TCP/IP connections or named pipes.

Another approach is to share only read-only data structures, which is why functional programming languages can work so well with multiple threads.