However much I would like it to, it does not seem that the thread and shared memory based model of programming concurrency is going to go away any time soon. So here is a theory on how to improve it.

I will start with a premise: the reason locking is such a problem in thread programming is because so much of it is implicit, and humans do a horrible job at remembering implicit things (especially implicit things at a distance). Thus to improve the situation, we need to make as much locking as possible explicit, and further, we need to do it in a non-annoying manner.

The best place for this is in the IDE, because the IDE has the best interface for telling you things (which is what's necessary to make locking explicit). To do this, the IDE needs to keep track of locks that are taken by code paths and locks that are required for access to specific objects; if done cleverly this doesn't need language changes, and the IDE can work out a lot of this by itself (probably with some annotations added by the programmer when the IDE falls down). While this is a bunch of parsing and code analysis, my impression is that powerful IDEs are already doing a lot of that as it is (at least in languages that are static enough to be amenable to it) and, for that matter, the IDE need not restrict itself to static analysis; in the same way that people profile code for performance, the IDE could profile the code for locking.

(One advantage of doing this in the IDE instead of the language is that IDEs are allowed to be incomplete and not entirely accurate, as long as they warn you about it. And you can turn the IDE's helpful information displays off if they turn out to be useless for your particular project.)

Once the IDE has this information, there's all sorts of things it can do with it. The simple thing is to colour or otherwise note the locks that are held when the code you're working on is run, and to similarly colour objects that you access and work with. Beyond that I'm sure there's a pile of visualization that can be done to give you a higher level view of your program's locking; if nothing else, Venn diagrams of lock overlap should be interesting in any decent-sized code base.

(Disclaimer: I can't be the first person to have this idea, and I wouldn't be surprised to find out that there are already IDEs that do this.)