I would argue that concurrent programming is something new. If you have 2 processors, then the worst thing that can happen is you get 50% of the machine's power per application - and if you have other processes running, they can use the other processor. In practice, on a dual-processor machine, you can completely ignore concurrency and often still get excellent performance for the majority of users, just by letting the OS worry about it for you. Particularly in the case where there is one long-running task in the background and one interactive task in the foreground, the user will get the best experience possible with no extra effort on the programmer.
The difference now is that with 32-cores (on the Sun T2000 for example) or more, unless you have a very easily partitioned workload (e.g. serving simple web pages), if you don't think about concurrency up front, your app will suck. With 32 cores, naive approaches to locking will rapidly drag performance into the mud. Working on massively multicore kit if you need a single task to dominate the system is a hard problem. Things are about to get interesting...
The difference now is that with 32-cores (on the Sun T2000 for example) or more, unless you have a very easily partitioned workload (e.g. serving simple web pages), if you don't think about concurrency up front, your app will suck. With 32 cores, naive approaches to locking will rapidly drag performance into the mud. Working on massively multicore kit if you need a single task to dominate the system is a hard problem. Things are about to get interesting...