I think part of the problem is that commute should not return any result.
You are not sure this is actually the value that will be returned,
this is costly
and misleading.
There should be at least a variant of commute that return nil.
--
You received this message because you are subscribed to
; > wrong, *throws question to the Gods of clojure*
> >
> >
> >
> >
> >
> >
> >
> > On Fri, May 18, 2012 at 8:03 AM, Warren Lynn
> wrote:
> > > Thanks and these are certainly workable solutions. But is there any
> > > particular reason
r as I know. Although I could be
> wrong, *throws question to the Gods of clojure*
>
>
>
>
>
>
>
> On Fri, May 18, 2012 at 8:03 AM, Warren Lynn wrote:
> > Thanks and these are certainly workable solutions. But is there any
> > particular reason why with commute t
way to tell that no
other thread has changed the Ref, as far as I know. Although I could be
wrong, *throws question to the Gods of clojure*
On Fri, May 18, 2012 at 8:03 AM, Warren Lynn wrote:
> Thanks and these are certainly workable solutions. But is there any
> particular reason why with commut
Thanks and these are certainly workable solutions. But is there any
particular reason why with commute the update function is ALWAYS
called twice, even when no other thread changed the ref value at the
commit time? That is what bothers me.
On May 17, 5:46 pm, DAemon wrote:
> Would some of t
I think the point with `commute` is to allow for more concurrency at the
> expense of more computation.
>
> If you want assurance that your function is only called once, you can use
> `alter`.
>
> Keep in mind that *any* code in a Ref transaction has the potential to be
> call
I think the point with `commute` is to allow for more concurrency at the
expense of more computation.
If you want assurance that your function is only called once, you can use
`alter`.
Keep in mind that *any* code in a Ref transaction has the potential to be
called more than once if there
Hi,
The duplicate computation in "commute" seems to me quite a blemish on
clojure's beauty. I even see somebody's code with comments "pre-
compute x because otherwise commute will call it twice". So I need to
keep that fact in the back of my mind when using it? Tha
01 pm, Moritz Ulrich
wrote:
> Read the documentation of commute
> carefully:http://richhickey.github.com/clojure/clojure.core-api.html#clojure.co...
>
> commute acts at the end of the current dosync-block, regardless of
> when commute was applied inside it. That's the reason why you c
Read the documentation of commute carefully:
http://richhickey.github.com/clojure/clojure.core-api.html#clojure.core/commute
commute acts at the end of the current dosync-block, regardless of
when commute was applied inside it. That's the reason why you can't
ref-set it after a co
Alter or ref-set a ref after commute would throw a
IllegalStateException:Can't set after commute
for example:
user=> (def counter (ref 0))
#'user/counter
(dosync (commute counter inc) (ref-set counter 3))
java.lang.IllegalStateException: Can't set after commute
(NO_SOURCE_FILE:
Dear all,
>>
>> Is there an equivalent of commute without return value?
>>
>> A part of the usage of commute just want to change something without
>> knowing the result.
>> (For example, I want to extend a set).
>>
>> I know it is not very expensive
On May 4, 2010, at 9:30 AM, Nicolas Oury wrote:
Dear all,
Is there an equivalent of commute without return value?
A part of the usage of commute just want to change something without
knowing the result.
(For example, I want to extend a set).
I know it is not very expensive but computing
Dear all,
Is there an equivalent of commute without return value?
A part of the usage of commute just want to change something without
knowing the result.
(For example, I want to extend a set).
I know it is not very expensive but computing twice a function - if
there is a bit of contention, but
It seems I have an example that shows difference between commute and
alter.
Here it is:
(defn my-inc [x] (dosync (Thread/sleep 1000) (inc x)))
alter***
(def x (ref 0))
(do
(def fut (future (do (Thread/sleep 300) (dosync (alter x inc))
@x)))
(dosync (println @x)(alter x my-inc
2010/2/18 Аркадий Рост :
> hmm..but in what way I can write code to demonstrate the difference?
You must reproduce the race conditions.
An idea is to start 2 transactions in 2 different threads, while
making the first one sleep sufficiently so you're sure the second one
will commit first.
Simply
hmm..but in what way I can write code to demonstrate the difference?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
2010/2/18 Аркадий Рост :
> Hi!
> I don't understand difference between commute and alter. In fact I
> don't understand how can I get different results by changing alter to
> commute in code.I've read that the in-transaction value with commute
> is that it may differ
Hi!
I don't understand difference between commute and alter. In fact I
don't understand how can I get different results by changing alter to
commute in code.I've read that the in-transaction value with commute
is that it may differ from the post-commit value, as the effect of
commut
B commits its change to Ref R.
5) Transaction A calls ensure on Ref R which succeeds because no
currently running transaction has modified Ref R.
6) Transaction A calls commute on Ref R.
7) Transaction A tries to commit.
8) Transaction A will retry because wasEnsured is true and the latest
comm
On Mon, Aug 17, 2009 at 2:34 AM, Christophe Grand wrote:
> Hi Mark and Meikel,
>
> On Mon, Aug 17, 2009 at 8:15 AM, Meikel Brandmeyer wrote:
>>
>> On Aug 17, 3:23 am, Mark Volkmann wrote:
>> > Maybe it's there in case ref-set or alter was called on the Ref bef
Hi Mark and Meikel,
On Mon, Aug 17, 2009 at 8:15 AM, Meikel Brandmeyer wrote:
>
> On Aug 17, 3:23 am, Mark Volkmann wrote:
> > Maybe it's there in case ref-set or alter was called on the Ref before
> commute.
> > In that case, does that mean that the commute functions
Hi,
On Aug 17, 3:23 am, Mark Volkmann wrote:
> Once commute has been called on a Ref (within a transaction of
> course), ref-set and alter cannot be called on it within the same
> transaction.
> This is enforced by the following code from the doSet method in
> LockingT
Once commute has been called on a Ref (within a transaction of
course), ref-set and alter cannot be called on it within the same
transaction.
This is enforced by the following code from the doSet method in
LockingTransaction.java.
if(commutes.containsKey(ref))
throw new
On Mon, Aug 3, 2009 at 5:44 AM, Christophe Grand wrote:
> I think Mark's code exhibits a bug:
>
> (def my-ref (ref 1))
>
> (dosync
> (ref-set my-ref 5)
> (commute my-ref inc)) ; returns 6
>
> (println "my-ref =" @my-ref) ; prints 7
>
> since my
I think Mark's code exhibits a bug:
(def my-ref (ref 1))
(dosync
(ref-set my-ref 5)
(commute my-ref inc)) ; returns 6
(println "my-ref =" @my-ref) ; prints 7
since my-ref is ref-set, my-ref is in LockingTransaction/sets but its
current value in LockingTransaction/vals is se
On Sun, Aug 2, 2009 at 8:54 PM, Mark Volkmann wrote:
>
> On Sun, Aug 2, 2009 at 5:45 PM, Rich Hickey wrote:
>>
>> On Sun, Aug 2, 2009 at 3:20 PM, Mark Volkmann
>> wrote:
>>>
>>> The doc for commute says "At the commit point of the transaction, sets
On Sun, Aug 2, 2009 at 5:45 PM, Rich Hickey wrote:
>
> On Sun, Aug 2, 2009 at 3:20 PM, Mark Volkmann
> wrote:
>>
>> The doc for commute says "At the commit point of the transaction, sets
>> the value of ref to be:
>> (apply fun most-recently-committed-val
On Sun, Aug 2, 2009 at 3:20 PM, Mark Volkmann wrote:
>
> The doc for commute says "At the commit point of the transaction, sets
> the value of ref to be:
> (apply fun most-recently-committed-value-of-ref args)".
>
> Looking at the source code in LockingTransaction.
I've been thinking about this more. Suppose I do something like this.
(def my-ref (ref 1))
(defn f1 []
(dosync
(ref-set my-ref 10)))
(defn f2 []
(dosync
(ref-set my-ref 5)
(commute my-ref #(inc %
(let [t1 (Thread. f1)
t2 (Thread. f2)]
(.start t1)
(.sta
The doc for commute says "At the commit point of the transaction, sets
the value of ref to be:
(apply fun most-recently-committed-value-of-ref args)".
Looking at the source code in LockingTransaction.java, that doesn't
seem to always be the case. I see this:
f.fn.applyTo(RT.co
On Feb 1, 2009, at 6:47 AM, Paul Barry wrote:
> My understanding of commute is that it would not restart the
> transaction, it would just apply the function. So I wrote this
> little test program:
>
> (defmacro in-thread [& body]
> `(.start
> (Thread.
>
My understanding of commute is that it would not restart the transaction, it
would just apply the function. So I wrote this little test program:
(defmacro in-thread [& body]
`(.start
(Thread.
(fn []
(println "Thread" (.getId (Thread/currentThread)) " started
> and perl has closure, so it looks commute uses closure concept
> > > My question is that conj takes two argument and how conj finds
> > > the first argument? Is it somehow provided by commute?
commute is passed conj as a function.
commute then calls conj messages msg,
an
Thanks Randall.
My background is mostly in imperative languages, including perl
and perl has closure, so it looks commute uses closure concept
to implement this. Is it right?
Thanks again,
sun
On Dec 16, 9:28 pm, Randall R Schulz wrote:
> On Tuesday 16 December 2008 18:10, wubbie wr
On Tuesday 16 December 2008 18:10, wubbie wrote:
> Hello,
>
> My question is that conj takes two argument and how conj finds
> the first argument? Is it somehow provided by commute?
Consider the documentation for (commute ...) (at
<http://
Hello,
My question is that conj takes two argument and how conj finds
the first argument? Is it somehow provided by commute?
Thanks,
sun
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
On Nov 26, 2:35 pm, "Mark Volkmann" <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 26, 2008 at 1:13 PM, Shawn Hoover <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Nov 26, 2008 at 1:55 PM, Mark Volkmann <[EMAIL PROTECTED]>
> > wrote:
>
> >> The doc
On Wed, Nov 26, 2008 at 1:13 PM, Shawn Hoover <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, Nov 26, 2008 at 1:55 PM, Mark Volkmann <[EMAIL PROTECTED]>
> wrote:
>>
>> The documentation for commute says "Sets the in-transaction-value of
>> ref ...". Th
On Wed, Nov 26, 2008 at 1:55 PM, Mark Volkmann <[EMAIL PROTECTED]>wrote:
>
> The documentation for commute says "Sets the in-transaction-value of
> ref ...". This implies to me that when the transaction ends, the ref
> will have its previous value.
>
> (def
The documentation for commute says "Sets the in-transaction-value of
ref ...". This implies to me that when the transaction ends, the ref
will have its previous value.
(def myRef (ref 19))
(dosync (commute myRef inc)) -> 20
@myRef -> 20
Why isn't the value of the last
On Aug 25, 3:33 pm, "Shawn Hoover" <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 25, 2008 at 11:57 AM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> > (def hits (ref 0))
> > (def cache (ref {:n nil :factors nil}))
> > (def cache-hits (ref 0))
>
> &
On Mon, Aug 25, 2008 at 11:57 AM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> (def hits (ref 0))
> (def cache (ref {:n nil :factors nil}))
> (def cache-hits (ref 0))
>
> (defn cached-factor [n]
> (dosync (commute hits inc))
> (let [cached @cache]
>(if
se(resp, factors);
> }
>
> }
>
> And in Clojure (stripping out the Servlet noise):
>
> (def *last-number* (ref nil))
> (def *last-factors* (ref nil))
> (def *count* (ref 0))
> (def *cache-hits* (ref 0))
>
> (defn cached-factor [n]
>(dosyn
44 matches
Mail list logo
