(original) (raw)
On Wed, Jan 11, 2012 at 7:01 PM, Mike Meyer <mwm@mired.org> wrote:
On Wed, 4 Jan 2012 00:07:27 -0500
PJ Eby <pje@telecommunity.com> wrote:
�> On Tue, Jan 3, 2012 at 7:40 PM, Mike Meyer <mwm@mired.org> wrote:
> > For> > instance, combining STM with explicit locking would allow explicitI thought about that. I couldn't convince myself that STM by itself
> > locking when IO was required,
> I don't think this idea makes any sense, since STM's don't really
> "lock", and to control I/O in an STM system you just STM-ize the
> queues. (Generally speaking.)
sufficient. If you need to make irreversible changes to the state of
an object, you can't use STM, so what do you use? Can every such
situation be handled by creating "safe" values then using an STM to
update them?
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.
In either case, though, the STM is pretty much sufficient, given a good enough queue data structure.