Message-ID: <1319681095.607.1369175444547.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_606_1609381580.1369175444547" ------=_Part_606_1609381580.1369175444547 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 quic= k sort, merge sort, file system or general tree navigation and such.
The mighty JSR-166y library solves Fork / Join = orchestration pretty nicely for us, but leaves a couple of rough edges, whi= ch can hurt you, if you don't pay attention enough. You still deal with thr= eads, pools and synchronization barriers.
GP= ars can hide the complexities of dealing with threads, pools, barriers and = RecursiveActions from you, yet let you leverage the powerful Fork/Join impl= ementation in jsr166y.
Fork/Join operations can be safely run with small n= umber of threads thanks to internally using the TaskBarrier class to synchr= onize the threads. While a thread is blocked inside an algorithm waiting fo= r 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. Although the algorithm creates as many tasks as there are sub= -directories and tasks wait for the sub-directory tasks to complete, as few= as one thread is enough to keep the computation going and eventually calcu= late a valid result.
If you'd like to know more, check out the Fork/Join section of = the User Guide.------=_Part_606_1609381580.1369175444547--