Fuzzyman <[EMAIL PROTECTED]> writes:
> STM isn't lock free - it just abstracts the locks away from the
> 'user'. You still need to lock around committing the transaction.
The idea is that readers don't need locks. They just look at the
version number before they start reading and after they finis
Hi,
I've received some great feedback since the initial beta release of
the minimalistic STM code I discussed and released 2 weeks ago. I've
incorporated the feedback, and created a couple of examples based on
the canonical dining philosophers example. (One based on normal python
threads, one bas
Hi,
I've packaged up the minimal STM discussed over the past couple of days as a
standalone package which I've now uploaded
Getting it
==
You can download a beta test version here:
http://thwackety.com/Axon.STM-1.0.0.tar.gz
Previewing it
=
You can look at the sourcecode
John J. Lee wrote:
> Durus might be worth a look too (though I doubt it's suitable for your
> situation):
>
> http://www.mems-exchange.org/software/durus/
>
> The link to their paper about it seems to be broken, but I think it
> was based somewhat on ZODB, but is simpler (67k tarball :-).
Much
Michael Sparks <[EMAIL PROTECTED]> writes:
> Duncan Booth wrote:
>
>> Michael Sparks <[EMAIL PROTECTED]> wrote:
>>
>>> I'm interested in writing a simple, minimalistic, non persistent (at
>>> this stage) software transactional memory (STM) module. The idea being
>>> it should be possible to write
Fuzzyman wrote:
>> STM seems more in
>> keeping with Kamaelia being generally lock-free.
>
> STM isn't lock free - it just abstracts the locks away from the
> 'user'. You still need to lock around committing the transaction.
>
I perhaps phrased what I meant too tersely.
Kamaelia isn't lock fre
Duncan Booth wrote:
> Michael Sparks <[EMAIL PROTECTED]> wrote:
>
>> I'm interested in writing a simple, minimalistic, non persistent (at
>> this stage) software transactional memory (STM) module. The idea being
>> it should be possible to write such a beast in a way that can be made
>> threadsaf
> STM seems more in
> keeping with Kamaelia being generally lock-free.
STM isn't lock free - it just abstracts the locks away from the
'user'. You still need to lock around committing the transaction.
Other threads accessing the data during the transaction should see the
old values until the commi
Michael Sparks <[EMAIL PROTECTED]> wrote:
> I'm interested in writing a simple, minimalistic, non persistent (at
> this stage) software transactional memory (STM) module. The idea being
> it should be possible to write such a beast in a way that can be made
> threadsafe fair easily.
>
> For those
Fuzzyman wrote:
> Wouldn't it be more useful having a store (possibly with a mapping
> API?) that stored several values. Then a single commit can be done at
> the end of the transaction.
>
> If the transaction fails, then the whole process can be repeated with
> none of the changes having been co
On Dec 8, 10:53 pm, Michael Sparks <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm interested in writing a simple, minimalistic, non persistent (at this
> stage) software transactional memory (STM) module. The idea being it should
> be possible to write such a beast in a way that can be made threadsafe fa
Hi,
I'm interested in writing a simple, minimalistic, non persistent (at this
stage) software transactional memory (STM) module. The idea being it should
be possible to write such a beast in a way that can be made threadsafe fair
easily.
For those who don't know, STM is a really fancy way of say
12 matches
Mail list logo
