Hi Neale,
I think refs #1 is fine as it stands. That said, perhaps this clarification
will help: "Start" means "as of current try", not "as of first try". If the
transaction has no way to see new things on retry, then the retry cannot
possibly succeed where the initial try failed.
Stu
> Hi,
>
> We're all agreed that the behaviour I'm seeing is because the READ
> transaction is re-starting. It sounds like the community thinks that's the
> right behaviour and I'm happy to be educated....
>
> I don't believe that the READ transaction should need to restart just because
> the underlying refs changed after it started and in fact if the refs have
> history then the READ transaction isn't restarted.
>
> I guess my observations could be re-phrased...
>
>
> Is it desirable that the semantics around transaction re-start where the
> transaction is purely a read-only transaction differ based on whether the
> refs have history or not.
>
>
> If everyone's happy that that's the case then an update to that point #1 on
> clojure.org/refs is probably in order, because that's not how it reads at the
> moment at least in my understanding.
>
> thanks for your time.
>
> Neale
> {t: @sw1nn, w: sw1nn.com }
>
>
>
> On Tue, Apr 17, 2012 at 7:20 AM, dennis zhuang <killme2...@gmail.com> wrote:
> 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:
> 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 willsee
> 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, 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, 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
