Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<h2>First of all</h2> <p>The usual disclaimer: concurrent programming, in any language, using any abstraction level, is <strong>hard</strong> and <strong>complicated</strong> and has many risks. Take into consideration:</p> <ul> <li>Concurrent programming complicates any application by magnitude</li> <li>Unit-testing critical sections is hard, and sometimes impossible</li> <li>Reproducing bugs originating in concurrent code is <strong>very hard</strong> and much dependent on architecture, OS flavor, version, etc...</li> </ul> <h2>Java Concurrent APIs</h2> <p>Java has gone a long way in making concurrent programming as easy as possible for developers. For most cases, you will see that <code>java.util.concurrent</code> has most of the abstractions you will need:</p> <ul> <li><strong><code>Runnable</code></strong> interface and <strong><code>Thread</code></strong> object you can extend. Just throw in your code and you have a thread ready to run</li> <li>A nice set of <strong><code>Executors</code></strong>: constant pool, dynamic pool, scheduled, or whatever. Just throw a <code>Runnable</code> at it and it does the rest.</li> <li><strong><code>Semaphore</code>s</strong> and <strong>locks</strong> of all sorts relieve you of needing to implement common locking techniques.</li> <li>A built-in <code>wait()</code> and <code>notify()</code> API for all objects.</li> </ul> <h2>Uses</h2> <p>The only thing left for you, as the software engineer, is to ensure you are writing <strong>correct</strong> code. Meaning you should be aware of the dangerous situations you might be exposing yourself to:</p> <ul> <li><strong>Deadlock</strong> - a situation in which two or more threads are waiting on unordered resources, rendering an infinite waiting loop.</li> <li><strong>Livelock</strong> - two or more threads which politely try to give way to the other on a shared resource but end up not taking it (consider two people in a corridor walking up to each other and constantly moving together from side to side)</li> <li><strong>Starvation</strong> - a single thread taking up most or all of a single shared resource, thus depriving other threads from access to it.</li> </ul> <h1>Main Point (or, when to use)</h1> <p><strong>Use threads only when concurrency will directly improve your applications behavior.</strong> </p> <p>If you are waiting on an IO/network/hardware-bound resource, <strong>DO</strong> spawn a thread on it so you can continue doing other stuff.</p> <p>If you are just trying to elegantly split CPU-bound computations, <strong>DO NOT</strong> use threads. You just might end up worsening your performance.</p> <p>If you do use threads, make sure you have thoroughly contemplated the risks, and triple-checked you did not miss any exceptional situations.</p> <h2>Useful (Online) Resources</h2> <p>Fastest way to get into things is to do the <a href="http://java.sun.com/docs/books/tutorial/essential/concurrency/" rel="nofollow noreferrer">Sun concurrency tutorial</a>. Other than that, get a good book.</p> <p>Good luck :)</p>
 

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