Following along with the principle of not optimizing too early, I'm wondering at what point in the design / development of a piece of software do you start thinking about the concurrency opportunities?I can well imagine that one strategy would be to write a single threaded application, and through profiling identify sections that are candidates to run in parallel.  Another strategy I've seen a little of is to consider the software by groups of tasks and to make the independent tasks parallel.Part of the reason for asking is that of course, if you wait until the end and only refactor the software to operate concurrently, you may structure things in the worst possible way and have a major task on your hand.What experiences have helped to determine when you consider parallelization in your design?
When developing a piece of software, when do you start thinking/designing the concurrent sections?
development process;multithreading;concurrency;parallelism
The thing about thread tasks is you want high cohesion, low coupling, and good encapsulation.  Interestingly enough, those happen to be worthy design goals for single-threaded applications as well.  I had a task today that I didn't originally plan on parallelizing, but when I did, it involved little more than renaming a function to run() and changing how it was called.Not optimizing too soon means don't put everything in a thread just in case, but neither should you paint yourself into an architectural corner so it will be too difficult to optimize should the need arise.