I really don't see threads being used explicitly more today then they were 10 years ago. The number of programmers who are proficient in dealing with locks, semaphores, etc...doesn't seem to have grown much (perhaps not outpacing the overall rate). If anything, we have a lot more code these days that is not explicitly multi-threaded but is implicitly concurrent in some other way that may or may not use threads under the covers (async, job managers).

Exactly, in fact I'd say there's a lot more multithreading going on today, it's just that it's hidden behind whatever JEE framework people are using. This isn't a bad thing, enterprise developers (i.e. 90% of us) shouldn't have to worry about mutexes any more than they have to worry about interrupts or sorting algorithms.

Out of interest, how does an enterprise developer (whatever that means) ensure consistency of data and good performance, the two competing aims of a decent mutex/lock strategy? Is it taken on trust that someone else handles this, and therefore hidden in 'safe' data structures or... ?

One place you see a lot of good "under the covers" stuff going on is with .Net 4.5. The task parallel stuff they have is really decent. You still have to think a little bit about concurrency issues, but if you are careful to use their thread safe structures, they have taken care of a lot of the harder parts for you. It is a neat model that just plays out pretty nicely.

Another cool product is Disruptor - they have figured out a good, fast way to do message passing that minimizes the need for concurrent data structures between worker threads. (Provided of course you can model your app in that way). Under the hood, they have some crazy dep memory barrier based stuff, but for most of the programmers on a team, thinking about that stuff is just not needed. (as an aside, I think if Beautiful Code 2 was being written, I think Disruptor should be included, that source code is downright inspiring.)

The point being, once you have a good, trusted and vetted set of primitives, and are willing to put a little effort into working in a paradigm someone else sets, you get a lot of benefit. This is no different than using RoR or Django instead of rolling your own web framework.

If threads or processes or distributed computing is being used under the covers, does it still count as multi-threaded programming? I could go out and design an machine/OS that didn't use what we would think of threads (think Atari's Transputer [1]), and all these implicit threaded schemes would still work with my new construct. Now, we might not have transputers, but some of us get to use GPUs and such (still niche, but growing), where the unit of parallelism no longer resembles a thread very much.

My point was that multi-threaded programming hasn't taken off because it hasn't needed to. We just get some really smart experienced guys to write our infrastructure that encapsulates thread use and all of us get to reuse that.

[1] http://en.wikipedia.org/wiki/Transputer

Somebody still needs to be the smart experienced guy. Somebody still needs to write the language VMs, low level libraries and interfaces, device support etc etc.

I really don't get on with this mindset that someone else can fix it.

I'm talking about higher level abstractions than concurrency frameworks integrated in Java or .Net . In an enterprise world, if you need to parallelise tasks between multiple consumers, you just add them to a JMS queue/topic and tweak some obscure xml to say who consumes it and how.

In fact, using any thread or concurrency mechanism in JEE code is considered a code smell, you should be handling it with the Spring/JMS/Jboss setup

Never done any JEE, or 'Enterprisey' coding in my life, so I wouldn't recognise code smell if it was waved under my nose :)

I've had the sort of career that involved highly-optimised in-memory databases, high-volume, low-latency payment processing and stuff like that. So I'm used to dealing with this stuff direct.