<br><div class="gmail_quote">On Thu, Nov 3, 2011 at 9:38 AM, Mike Meyer <span dir="ltr"><<a href="mailto:mwm@mired.org" target="_blank">mwm@mired.org</a>></span> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
<span style="font-family:arial, sans-serif;font-size:13px;background-color:rgb(255, 255, 255)">Attributes are names. You don't lock names, you lock objects. To<br></span><span style="font-family:arial, sans-serif;font-size:13px;background-color:rgb(255, 255, 255)">prevent binding of an attribute, you lock the object it's an attribute<br>
</span><span style="font-family:arial, sans-serif;font-size:13px;background-color:rgb(255, 255, 255)">of. If you want to prevent mutating the value of the object bound to<br></span><span style="font-family:arial, sans-serif;font-size:13px;background-color:rgb(255, 255, 255)">the attribute, you lock that object.</span></blockquote>
<div><br></div><div>You conveniently ignore my comment about the importance of database row locking. :-) </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
> (3) What happens if one thread does:<br>
><br>
> locking d, x: # stuff<br>
><br>
> and another does<br>
><br>
> locking x, d: # stuff<br>
<br>
</div>That one I dealt with in the specification. There's an implementation<br>
requirement that if two locking statements share objects, the shared<br>
objects have to be locked in the same order. So one of the two will<br>
lock things in the opposite of the order they appear in the statement.<br>
<div></div></blockquote></div><br><div>You're handwaving. How would that work? There's no way to know at compile time what the correct order is. So locking just got a whole lot more complicated. But it's worse than complicated: it's unworkable.</div>
<div><br></div><div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); ">No, avoiding deadlock is one of the goals. That's why that requirement<br></span><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); ">exists, and there's a further requirement that you can only nest<br>
</span><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); ">locking statements if the inner one locks a subset of the outer one.<br></span></blockquote>
<div><br></div><div>In other words, this code is not allowed:</div><div><br></div></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div>def f():</div></div><div>
<div> locking x:</div></div><div><div> for y in x:</div></div><div><div> locking y:</div></div><div><div> y.append(1)</div></div></blockquote><div><div><br></div></div><div>And neither is this:</div>
<div><br></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div>def f(x):</div></div><div><div> locking x:</div></div><div><div> x.append(1)</div></div>
</blockquote><div><div><br></div></div><div>if it is called inside code that has something locked. Which virtually all code will do since it's required everywhere. So your proposal is that I must lock everything before I change it but I can't lock it unless it's already locked. That's ridiculous. You might as well have a single semaphore to lock everything.</div>
<div><br></div><div>We're wasting our time. You said above "You don't lock names, you lock objects." Why not? Because that was your original plan and your mind is closed to other ideas? You want to ignore legitimate issues that aren't convenient to your proposal. I hate to say things like "this idea sucks," but sometimes that's the only way to put it. I think that this proposal is a terrible idea. It's pointless to argue about the details of something this bad. A healthy discussion about how to make concurrency better might be interesting but as long as all you want to do is defend your proposal, this thread isn't sparking useful discussion. Sorry to be so blunt but I don't see any other way to get the message across.</div>
<div><br></div><div>--- Bruce</div>