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 progr
> 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
*
On Wed, Sep 23, 2009 at 10:17 AM, Christophe Grand
wrote:
>
>
> On Wed, Sep 23, 2009 at 7:14 AM, Timothy Pratley
> wrote:
>>
>> 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 expec
On Wed, Sep 23, 2009 at 7:14 AM, Timothy Pratley
wrote:
> 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 automatically ensure within a
> d
On Sep 23, 9:23 am, Dave Jack 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 function called a
> 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
o
> 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
>> .. 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 "Clojur
> How can I be sure that no more data is added to data after @consuming
> was set to true ?
You need to prevent the modification of consuming by using ensure
rather than deref (@).
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
On Tue, Sep 22, 2009 at 3:18 PM, Roger Gilliar 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 rereadi
> 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 h
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
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
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 (ref-
14 matches
Mail list logo
