On Mon, Oct 31, 2011 at 11:00 PM, Greg Ewing email@example.com:
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.