I'd like to point out an issue, which has impact on performance. On multicore systems, each CPU has its own cache, and possibly a local copy of a variable. Writes on one CPU are not immediately visible on another. Thus, doing a job on one thread (CPU), and suddenly turning that job to another thread is not a good solution. I prefer specialized threads each doing a specific job, on specific data. Then no need for synchronization, if it is sure, that some data always belong to a specific thread.
It seems like you are confusing threads with cores. The OS will take care of managing your threads. You never have to do synchronization with data that is only read and written on the same thread. The OS and hardware will take care of moving the data needed to another core, if needed.
I'm not confusing threads with cores, but given a situation where the machine has multiple cores, threads can run on different cores, which has impact on their behaviour.
"You never have to do synchronization with data that is only read and written on the same thread."
Yeah, thats what i'm saying too. Its better to design the program so, that certain data is localised to a certain thread, than to make everything a task and throw it on a thread-pool.
"The OS and hardware will take care of moving the data needed to another core, if needed."
Isn't true. You have to declare variables volatile, and put code into synchronized blocks is you want to maintain integrity. But the goal is to avoid the need for such integrity, by making every thread run as much independently of other threads as possible.
Forget the thread-pool. Data ownership is important. If you read about X10, you will see, that the whole language is about managing the ownership of the data, and managing it manually, by the programmer.