All for very different reasons, processor vendors, software developers and industry gurus are engaged in talk frenzies about how to leverage multiple core hardware. Some consider the dangers. Some even fight about it.
Beside the obvious enthusiasm of experimenting such a surge of computing power right under our fingers, exploiting this power requires a skillset that is not widely available, at least not in the world of the ugly enterprise applications where people have to develop for the naturally parallelized environments that are application servers.
In this austere world of server side business applications, which are not CPU intensive but are greedy of external resources like RDBMS, there is not much room for developer hand made parallelizing of tasks: it is usually limited to executing long running operations via decoupling mechanisms like messaging.
This said, there are many ways to hurt your server by developing applications in a careless way. Assessing your skills (or your troops) is essential: this is why, following the model of the great Threading Maturity Model introduced by Alan Zeichick a few days ago, I would like to introduce the Threader Maturity Model, oriented towards people and not organization.
0. Unawareness. Complete rooky who writes a web application that can only accommodate one concurrent user and complains why is the server not working better (do not ask for names).
1. Awareness. Developer who has bumped on concurrency discussions, found them scary and prefers to let a more senior programmer deal with threading and concurrency.
2. Experimentation. Developer who dares playing with threads and concurrency, but still errs on the side of double-checked locking, interruption swallowing and the likes.
3. Hotspot. Developer has read enough on the subject and has crashed into enough walls to decide to program carefully, with still a certain level of insecurity and the fear of thread skeletons hiding in some dark closets.
4. Utilization. Developer has an excellent knowledge of concurrency issues and has a toolbox well fitted with patterns he knows when to apply and for what purpose. He can decide what is worth to parallelize and what is not.
5. Adoption. This is also known as "Being Brian Goetz". At this level, the developer has an intimate knowledge of the memory model, the concurrency mechanisms and all that pesky internal details. He is able to think in all the dimensions of multi-threaded development (time, space and whatnot). Nirvana is nearby.
UPDATE 01/2008: Alexandra Weber Morales has published a great compilation of Alan's, Larry's and my take on this subject. It is on DevX.
