On Jun 19, 2:44 pm, Rich Hickey wrote:
> On Fri, Jun 19, 2009 at 9:35 AM, Eric Willigers wrote:
>
> > On Jun 18, 9:35 pm, Rich Hickey wrote:
> >>http://clojure.org/refs
>
> >> point #8:
>
> >> "If a constraint on the validity of a value of a Ref that is being
> >> changed depends upon the simu
On Fri, Jun 19, 2009 at 9:35 AM, Eric Willigers wrote:
>
> On Jun 18, 9:35 pm, Rich Hickey wrote:
>> http://clojure.org/refs
>>
>> point #8:
>>
>> "If a constraint on the validity of a value of a Ref that is being
>> changed depends upon the simultaneous value of a Ref that is not being
>> change
On Jun 18, 9:35 pm, Rich Hickey wrote:
> http://clojure.org/refs
>
> point #8:
>
> "If a constraint on the validity of a value of a Ref that is being
> changed depends upon the simultaneous value of a Ref that is not being
> changed, that second Ref can be protected from modification by calli
On Jun 18, 2009, at 2:38 AM, Eric Willigers wrote:
>
> Hi all,
>
> I'm enjoying using Clojure. It is clean, concise and powerful.
>
> The containers and even defmacro are easy to use correctly. However,
> I'm yet to be convinced the same applies with the STM implementation.
>
> In the user code
You can use `ensure` if you want to make sure that the transaction
fails if a or b are altered while the threads are sleeping in your
example:
http://clojure.org/api#ensure
Otherwise, regarding serializable concurrency level: If you want
mutual exclusion, then that's what locks are for.
On Thu,
Hi all,
I'm enjoying using Clojure. It is clean, concise and powerful.
The containers and even defmacro are easy to use correctly. However,
I'm yet to be convinced the same applies with the STM implementation.
In the user code below, people might expect b == a + 1 after the two
transactions r
