When it useful to be able to deref inside a dosync without ensuring?
When you deref and alter/set the same ref, the ref is protected from
modification as well.
I couldn't think of an example of what I think you had in mind,
something that requires a transaction but is tolerant of modification
On Sep 23, 9:23 am, Dave Jack dav...@gmail.com wrote:
Maybe @ should expand to ensure rather
than deref inside a transaction, instead?
Should've thought about this more. How is the reader supposed to know
that this code is called in a transaction? And it would leak if you
deref'd inside a
On Wed, Sep 23, 2009 at 7:14 AM, Timothy Pratley
timothyprat...@gmail.comwrote:
When it useful to be able to deref inside a dosync without ensuring?
In a read-only transaction.
Ensure seems like a more safe default of what I'd expect from a
transaction. So why not make deref
On Wed, Sep 23, 2009 at 10:17 AM, Christophe Grand
christo...@cgrand.net wrote:
On Wed, Sep 23, 2009 at 7:14 AM, Timothy Pratley timothyprat...@gmail.com
wrote:
When it useful to be able to deref inside a dosync without ensuring?
In a read-only transaction.
Ensure seems like a more
And even then, ensure is often not needed and overkill. Make sure you
have a real business requirement that the predicate remain true (or
value fixed) on transaction completion. We need to move to a world in
--
It seems that my problem falls exactly in this category. Ensuring
Ok so there are two use cases:
1) testing constraint
2) referencing a snapshot
And two operations
A) @
B) ensure
1A is incorrect
1B is correct
2A is correct and concurrent
2B is correct but not concurrent
More concurrency is the default. This increases the chance of
incorrectness due to
I can't claim this is better, but it is shorter - I simply removed
what seemed like some unnecessary syntax:
(def data (ref ()))
(def consuming (ref false))
(defn producer []
(if (dosync (if (not @consuming)
(alter data conj 1)))
(recur)))
(defn consumer []
(dosync
Hi,
thanks a lot. Your code looks much better than mine. But there is one
part that I don't understand:
(defn producer []
(if (dosync (if (not @consuming)
(alter data conj 1)))
(recur)))
How can I be sure that no more data is added to data after @consuming
was set to
Hi, I gave it a try to find a solution to your problem. I ended up
using a single atom to hold the produced data and as means to detect
that consuming started (by swapping in a fn wrapping the produced
value). Don't know wether this fits your problem better than the one
already posted.
(def data
thanks a lot. Your code looks much better than mine. But there is one
part that I don't understand:
(defn producer []
(if (dosync (if (not @consuming)
(alter data conj 1)))
(recur)))
After rereading the docs several times It seems that I begin to
understand how this
On Tue, Sep 22, 2009 at 3:18 PM, Roger Gilliar ro...@gilliar.de wrote:
thanks a lot. Your code looks much better than mine. But there is one
part that I don't understand:
(defn producer []
(if (dosync (if (not @consuming)
(alter data conj 1)))
(recur)))
After
.. It waits until the value is actually needed. For
more details on this, see http://ociweb.com/mark/stm/article.html.
.
Great article.Thanks !
Roger
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Clojure
You need to prevent the modification of consuming by using ensure
rather than deref (@).
Oh - excellent point! I didn't think of that.
When it useful to be able to deref inside a dosync without ensuring?
Ensure seems like a more safe default of what I'd expect from a
transaction. So why not
This is some sort of repost from yesterday. But I hope that this one
describes my problem more precisely.
I have n threads that produce something. At some point in time a
consumer starts and if the consumer starts, no more data should be
produced. Right now I can only come up with the
14 matches
Mail list logo
