Message-ID: <469241598.2115.1429385985616.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_2114_1207484364.1429385985616" ------=_Part_2114_1207484364.1429385985616 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Fork/Join or Divide and Conquer is a very powerful abstraction t= o solve hierarchical problems.
When talking about hierarchical problems, think about quick sort, merge = sort, file system or general tree navigation and such.
The mighty JSR-166y library solves Fork / Join orchestr= ation pretty nicely for us, but leaves a couple of rough edges, which can h= urt you, if you don't pay attention enough. You still deal with threads, po= ols and synchronization barriers.
GPars can hide the complexities of dealing with threads, pools, barriers= and RecursiveActions from you, yet let you leverage the powerful Fork/Join= implementation in jsr166y.
Fork/Join operations can be safely run with small number of threads than= ks to internally using the TaskBarrier class to synchronize the threads. Wh= ile a thread is blocked inside an algorithm waiting for its sub-problems to= be calculated, the thread is silently returned to the pool to take on any = of the available sub-problems from the task queue and process them. Althoug= h the algorithm creates as many tasks as there are sub-directories and task= s wait for the sub-directory tasks to complete, as few as one thread is eno= ugh to keep the computation going and eventually calculate a valid result.<= /p>
If you'd like to know more, check out the Fork/Join section of the User Guide.