It's not uncommon to hear of decoupling the UI from program logic, or database design/access from program logic...or even program logic from itself.

However, I've never heard of an approach to generalizing or abstracting away the details of threading tasks to the logic (aside from Tymeac, an Android-specific package). Honestly, with all of the details going into managing threads, I don't expect many solutions to work well anytime soon, so...

My question is, how do you write threads that aren't joined at the hip to the processes that use those threads? What do you normally do when requirements change in an already complicated multi-threaded application? Is there a design approach to this that I should read?

I ask this because we are the dawn of the "bagillion"-core era in computing. Eventually, a good methodology will have to exist to manage 1k+ cores and even more threads here in the next couple of decades.

  • For Java use Executors.
    – user1249
    Dec 18, 2011 at 23:19

2 Answers 2


Despite wikipedia not listing threading specifically as a cross cutting concern I would almost say it is one. Finding a way to partition your data so that the resulting chunks are independent enough to be calculated in a thread is hard and highly dependent on your specific problem.

There are approaches to separate out threading, mostly patterns. Master-Worker, Thread Pool, you name it. They often rely on defining tasks, executing them and writing the results back into some data structure.

Unfortunately these patterns have only limited use when you want to have your word processor take advantage of your new 64-core machine.

Another approach are functional programming languages, the fact that they are inherently parallel, takes away some of the complexity with multi-threading. But they are only one puzzle piece in solving this problem and I am afraid you have to know a large list of techniques. In multithreading there is no "one size fits all".

  • I understand now that if one piece of a task changes, and that task was accomplished with threading, most (or all) of the process must be scrapped and rebuilt. Threads are tightly bound to themselves, but become portable once they are sealed off within it's own parallel algorithm. Thanks for the references, I learned a lot from this.
    – yurisich
    Dec 10, 2011 at 16:30
  • @Droogans Glad I could help ;-) Dec 11, 2011 at 8:32

Take a look at Apple's Grand Central Dispatch, which lets programmers take advantage of multiple processors without having to manage threads. The heart of GCD is libdispatch, available under an Apache license, so you can look at the source if you really want to see how to manage generic worker threads. libdispatch is apparently available in FreeBSD if you'd like to try it out but aren't working in MacOS X or iOS.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.