Hi,

  I know your meaning.But it is real that the read transaction is
restarted,you can observer it by stm-profile:
https://github.com/killme2008/stm-profiler

  (.start (Thread.
         #(do (Thread/sleep 10000)
         (prn (ref-stats r1)))))

  (Thread/sleep 20000000)

r1 statistics:

   {:deref 2, :get-fault 1}

It meant that r1's dereference get fault once,because no version of r1
value precedes the read point in the first transaction.

Clojure STM deference value from new to old,that the newest value will be
in ref history queue head,and it found that the newest value's point is
great than transaction read point,so the tx is restarted.I think that
in-transaction value means that you can change the value in the transaction
in an atomic way and is thread safe that you don't have to worry about
concurrency.It's consistent in the transaction,but it may be not consistent
with other transactions.


2012/4/17 Neale Swinnerton <ne...@isismanor.com>

>
> Hi Stu,
>
> The point is that there's no reason for the READ transaction to restart,
> it has only made reads of refs and those reads should be consistent with
> each other from the snapshot of the the ref world as per...
>
> In practice, this means:
>
>    1. All reads of Refs will see a consistent snapshot of the 'Ref world'
>    as of the starting point of the transaction (its 'read point'). The
>    transaction *will*see any changes it has made. This is called the *
>    in-transaction-value*
>
> *
> *
> from: http://clojure.org/refs
>
> The fact that the behaviour changes in the presence of history is a
> problem in my opinion.
>
> Yes you can 'ensure' that the refs aren't modified, but that means writes
> are blocked by reads - is that desired?
>
> Neale
> {t: @sw1nn <https://twitter.com/#!/sw1nn>, w: sw1nn.com }
>
>
>
> On Tue, Apr 17, 2012 at 2:59 AM, Stuart Halloway <
> stuart.hallo...@gmail.com> wrote:
>
>> Hi,
>>
>> [disclojure]: I've asked about this on SO, but figured out what was
>> happening myself[1] and that led to this enquiry.
>>
>>
>> It seems that the consistency of refs within an STM transaction (dosync)
>> depends on whether the ref has history.
>>
>> So if you create 2 refs and then read them in a transaction they could be
>> inconsistent with each other. i.e they won't necessarily return the value
>> the ref had at the start of the transaction.
>>
>>
>> However, if you give the refs some history by updating them in a prior
>> transaction, then the two refs will be consistent with each other in
>> subsequent transactions.
>>
>> This seems rather dangerous to me. Is there a rational for not creating
>> at least 1 history entry for a ref at ref creation time.
>>
>> Neale
>> {t: @sw1nn <https://twitter.com/#!/sw1nn>, w: sw1nn.com }
>>
>>
>> [1]
>> http://stackoverflow.com/questions/10178639/are-refs-really-consistent-within-a-stm-transaction
>>
>>
>> Hi Neale,
>>
>> Your example does not appear to match your conclusion. It shows that a
>> transaction restarts, and that the reads are all consistent as of the
>> restarted transaction.
>>
>> Cheers,
>> Stu
>>
>>
>> Stuart Halloway
>> Clojure/core
>> http://clojure.com
>>
>>
>>  --
>> 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
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
>
>  --
> 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
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>



-- 
庄晓丹
Email:        killme2...@gmail.com xzhu...@avos.com
Site:           http://fnil.net
Twitter:      @killme2008

-- 
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 your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Reply via email to