On Wed, Jan 11, 2012 at 7:01 PM, Mike Meyer <span dir="ltr"><<a href="mailto:mwm@mired.org">mwm@mired.org</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">
<div class="im">On Wed, 4 Jan 2012 00:07:27 -0500<br>
PJ Eby <<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>> wrote:<br>
> On Tue, Jan 3, 2012 at 7:40 PM, Mike Meyer <<a href="mailto:mwm@mired.org">mwm@mired.org</a>> wrote:<br>
</div><div class="im">> > For</div><div class="im">
> > instance, combining STM with explicit locking would allow explicit<br>
> > locking when IO was required,<br>
> I don't think this idea makes any sense, since STM's don't really<br>
> "lock", and to control I/O in an STM system you just STM-ize the<br>
> queues. (Generally speaking.)<br>
<br>
</div>I thought about that. I couldn't convince myself that STM by itself<br>
sufficient. If you need to make irreversible changes to the state of<br>
an object, you can't use STM, so what do you use? Can every such<br>
situation be handled by creating "safe" values then using an STM to<br>
update them?<br></blockquote><div><br></div><div>If you need to do something irreversible, you just need to use an STM-controlled queue, with something that reads from it to do the irreversible things. The catch is that your queue design has to support guaranteed-successful item removal, since if the dequeue transaction fails, it's too late. Alternately, the queue reader can commit removal first, then perform the irreversible operation... but leave open a short window for failure. It depends on the precise semantics you're looking for.</div>
<div><br></div><div>In either case, though, the STM is pretty much sufficient, given a good enough queue data structure.</div></div>