Mike Meyer wrote:

The goal here is to move from where we are to a place similar to where handling files is, so that failing to properly deal with the possibility of concurrent access causes an error when it happens, not at a point distant in both time and space.

I don't think what you're suggesting would achieve this,
though. The locking required for correctness often involves
more than one object or more than one operation on an
object. Consider

new_balance = balance + deposit
lock(balance)
balance = new_balance
unlock(balance)

This wouldn't trigger any of your alarms, but it would
still be wrong.

You're right - I chose my words poorly. As stated, solving it would involve solving the halting problem. Replace the word "properly" with "at all". I.e. - if you don't think about a concurrent access and should have, it'll cause an error. If you think about it and get it wrong - well, nothing will prevent all bugs. Partially automated resource allocation doesn't prevent the programmer from writing bad code, and this is in that category.

<mike