Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Learning to write multi-threaded programs correctly is extremely difficult and time consuming.</p> <p>So the first step is: replace the implementation with one that doesn't use multiple threads at all.</p> <p>Then carefully put threading back in if, and only if, you discover a genuine need for it, when you've figured out some very simple safe ways to do so. A non-threaded implementation that works reliably is far better than a broken threaded implementation.</p> <p>When you're ready to start, favour designs that use thread-safe queues to transfer work items between threads and take care to ensure that those work items are accessed only by one thread at a time.</p> <p>Try to avoid just spraying <code>lock</code> blocks around your code in the hope that it will become thread-safe. It doesn't work. Eventually, two code paths will acquire the same locks in a different order, and everything will grind to a halt (once every two weeks, on a customer's server). This is especially likely if you combine threads with firing events, and you hold the lock while you fire the event - the handler may take out another lock, and now you have a pair of locks held in a particular order. What if they're taken out in the opposite order in some other situation?</p> <p>In short, this is such a big and difficult subject that I think it is potentially misleading to give a few pointers in a short answer and say "Off you go!" - I'm sure that's not the intention of the many learned people giving answers here, but that is the impression many get from summarised advice.</p> <p>Instead, <a href="http://rads.stackoverflow.com/amzn/click/032143482X" rel="noreferrer">buy this book</a>.</p> <p>Here is a very nicely worded summary <a href="http://www.albahari.com/threading/" rel="noreferrer">from this site</a>:</p> <blockquote> <p>Multithreading also comes with disadvantages. The biggest is that it can lead to vastly more complex programs. Having multiple threads does not in itself create complexity; it's the interaction between the threads that creates complexity. This applies whether or not the interaction is intentional, and can result long development cycles, as well as an ongoing susceptibility to intermittent and non-reproducable bugs. For this reason, it pays to keep such interaction in a multi-threaded design simple – or not use multithreading at all – unless you have a peculiar penchant for re-writing and debugging!</p> </blockquote> <p><a href="http://www.daniweb.com/software-development/cpp/interviews/313564" rel="noreferrer">Perfect summary from Stroustrup</a>:</p> <blockquote> <p>The traditional way of dealing with concurrency by letting a bunch of threads loose in a single address space and then using locks to try to cope with the resulting data races and coordination problems is probably the worst possible in terms of correctness and comprehensibility.</p> </blockquote>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload