On Mon, Oct 31, 2011 at 11:00 PM, Greg Ewing <span dir="ltr"><<a href="mailto:greg.ewing@canterbury.ac.nz">greg.ewing@canterbury.ac.nz</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Mike Meyer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>

</blockquote>
<br>
I don't think what you're suggesting would achieve this,<br>
though. The locking required for correctness often involves<br>
more than one object or more than one operation on an<br>
object. Consider<br>
<br>
   new_balance = balance + deposit<br>
   lock(balance)<br>
   balance = new_balance<br>
   unlock(balance)<br>
<br>
This wouldn't trigger any of your alarms, but it would<br>
still be wrong.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>    <mike</div></div>