Re: Concurrency: hypothetical variables and atomic blocks
Darren Duncan schreef: > Each time a context (a code block, either a routine or a syntactic > construct like 'try' is) is entered that is marked 'is atomic', a new > transaction begins, which as a whole can later be committed or rolled > back; it implicitly commits if that context is exited normally, and > it rollsback implicitly if the context exits with a 'fail' and/or due > to a thrown exception. (And yes, I see it as being easier to use if > rollback and fail are generally joined at the hip.) There are also 'lazy atomic' actions that may not achieve (yet) what they are supposed to do (maybe the storage of some memory structure to a disk file). So they sort of 'try' and then sort of 'fail', but they shouldn't block continuation yet, because they will get another go at it later on. > One atomic context can contain another atomic context, so they are > layered; if an outer layer rolls back, it results in any 'successful' > inner layers also rolling back, so that everything which happened > within the outer context has rolled back. If the 'results' would be (for example) text data written to a logfile, the 'roll back' could be (1) removal of the written data, or (2) appending a line about the failure. But writing that last line can of course also fail. -- Groet, Ruud
Re: Concurrency: hypothetical variables and atomic blocks
On Thu, Jun 01, 2006 at 11:52:59AM +1200, Sam Vilain wrote: : The lock on entry approach will only be for non-threaded interpreters : that don't know how to do real STM. The way I see it, the fundamental difference is that with ordinary locking, you're locking in real time, whereas with STM you potentially have the ability to virtualize time to see if there's a way to order the locks in virtual time such that they still make sense. Then you just pretend that things happened in that order. As for side-effecty ops, many of them can just be a promise to perform the op later when the transaction is committed, I suspect. Larry
Re: Concurrency: hypothetical variables and atomic blocks
Larry Wall wrote: The way I see it, the fundamental difference is that with ordinary locking, you're locking in real time, whereas with STM you potentially have the ability to virtualize time to see if there's a way to order the locks in virtual time such that they still make sense. Then you just pretend that things happened in that order. Forgive this ignorant soul; but what is "STM"? -- Jonathan "Dataweaver" Lang
Re: Concurrency: hypothetical variables and atomic blocks
On Thu, Jun 01, 2006 at 02:22:12PM -0700, Jonathan Lang wrote: > Larry Wall wrote: > >The way I see it, the fundamental difference is that with ordinary > >locking, you're locking in real time, whereas with STM you potentially > >have the ability to virtualize time to see if there's a way to order > >the locks in virtual time such that they still make sense. Then you > >just pretend that things happened in that order. > > Forgive this ignorant soul; but what is "STM"? Software Transaction Memory -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
