<Higher-Order Fork/Join Operators ⁄ >

I think we can all agree that concurrency is a problem. Not really a problem as in "lets get rid of it", but more the type of problem that really smart people spend their entire lives trying to solve. Over the years, many different solutions have been proposed, some of them low-level, some more abstract. However, despite their differences, a common thread runs through all of these ideas: each of them attempts to ease the pain of decomposing operations in a reorderable fashion.

Surprisingly, the word "ordering" is not often heard in conjunction with parallelism. Most of the time, people are thinking in terms of server/client or broker/investor. If you really deconstruct the issue though, there is actually a deeper question underlying all concurrency: what operations do not depend upon each other in a sequential fashion? As soon as we identify these critical operations, we're one step closer to being able to effectively optimize a particular algorithm with respect to asynchronous processing.

By the way, I really will get to fork/join a little later, but I wanted to be sure that I had laid a solid groundwork for the road ahead. Without understanding some of the fundamental theory behind fork/join, it will be impossible to see how it can be applied effectively to your next project.



este é só um excerto do artigo, para aceder ao artigo completo, clique no link em baixo:
this is just a small excerpt from the article, to access the full article please click in the link below:
http://www.codecommit.com/blog/scala/higher-order-fork-join-operators