Hi all,
(my first post, let's hope it shows up soon)
On Tuesday, April 17, 2012 7:35:52 AM UTC+1, sw1nn wrote:
>
> 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....
>
Not the "right" thing but one possible thing and the inevitable one in this
case (see below). Anyway, in both outcomes no inconsistency is observed.
>
> 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.
>
The need to restart involves history because it is history that will
determine whether some past value can be obtained, more precisely, the
value at transaction start time. The important point to notice is that when
the transaction starts it does not know which refs it will need in the
future, so no read of r1 is done. Later after the sleep, when it tries to
dereference r1 it notices that the desired value corresponding to the
transaction start time is no longer available (as it was overwritten by
other transactions) and it causes a restart.
Also, whether or not there is a restart is not a history/no-history issue
but a "is there enough history?" and for the outcome it does not matter
that piece of code you posted in SO ref-setting the refs in the beginning.
Let's see:
- when the transaction starts the first time, the desired value to be read
for r1 is 0.
- as the transaction does not read it for some time, the other 3
transactions change it 3 times: 0 -> 1 -> 2 -> 3.
- when the transaction finally derefs r1 it no longer can access the value
at start time (0) and needs to restart.
- it would not need to restart if it could read the value 3 updates in the
past. This means that in this case it it is enough to use a
(def r1 (ref 0 :min-history H))
with H >= 3 for it not to restart. With insufficient (or no) history no
other option than restarting is possible ...
Regards,
Paulo
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
>>>
>>
>>
>>
>> --
>> 庄晓丹
>> 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
>>
>
>
--
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
