Re: Inconsistent refs within an STM transaction.
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.comwrote:
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.comwrote:
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 1)
(prn (ref-stats r1)
(Thread/sleep 2000)
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
Re: Inconsistent refs within an STM transaction.
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 1)
(prn (ref-stats r1)
(Thread/sleep 2000)
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
Inconsistent refs within an STM transaction.
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
--
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
Re: Inconsistent refs within an STM transaction.
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
Re: Inconsistent refs within an STM transaction.
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. I haven't looken into your examples in detail, but clojure has http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/ensure to get consistent reads. I don't know exactly why read skew is allowed by default. Maybe it's along the lines of: If reads were consistent by default, performance would suffer and write skew would still be possible (which can be prevented by (ref-set ref @ref)) kind regards -- 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
Re: Inconsistent refs within an STM transaction.
Hi Transaction read point is changed every time when transaction is started or retried.So the result is all right.If you want the ref1 cloud not be modified by other transactions ,you can use ensure: (defn deref-delay-deref [ref1 ref2 delay] (.start (Thread. #((println READ start) (dosync (println transaction starting) * (ensure ref1)* (let [a @ref2] (Thread/sleep delay) (println S r1= @ref1))) ; should be consistent with @ref2 (println READ end) 2012/4/17 Herwig Hochleitner hhochleit...@gmail.com 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. I haven't looken into your examples in detail, but clojure has http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/ensure to get consistent reads. I don't know exactly why read skew is allowed by default. Maybe it's along the lines of: If reads were consistent by default, performance would suffer and write skew would still be possible (which can be prevented by (ref-set ref @ref)) kind regards -- 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
Re: Inconsistent refs within an STM transaction.
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.comwrote:
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
