Thanks everyone for taking time on this. I've got it now.
My two take-aways:
* There was never any inconsistent result (and there never would be)
* worrying about transaction re-start is wrong - transactions might
re-start and the transactional code MUST always be correct under restart.
Neale
{t: @sw1nn <https://twitter.com/#!/sw1nn>, w: sw1nn.com }
On Wed, Apr 18, 2012 at 3:34 AM, Stuart Halloway
<stuart.hallo...@gmail.com>wrote:
> 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 <https://twitter.com/#!/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:
>>>
>>> 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
