Transactions in Clojure are "optimistic": the runtime assumes that
everything will work out, and if not, it retries.
Basically, when a transaction starts, the runtime makes a copy of the
current value of all refs involved in the transaction (these are assumed to
be immutable values, so copies are
Gary, thank you!
kl. 22:41:02 UTC+1 søndag 26. oktober 2014 skrev Gary Verhaegen følgende:
>
> Transactions themselves are not queued (besides the obvious queueing
> of threads when you have more threads than cores). What gets
> adaptively queued is the historical values of refs involved in
> t
Loan, thank you!
kl. 21:03:59 UTC+1 søndag 26. oktober 2014 skrev Leon Grapenthin følgende:
>
>
>
> On Sunday, October 26, 2014 11:37:43 AM UTC+1, Øyvind Teig wrote:
>>
>> I have been reading myself up on Clojure concurrency, starting at [1]. In
>> [2] I read that
>>
>> The Clojure STM uses multi
Transactions themselves are not queued (besides the obvious queueing
of threads when you have more threads than cores). What gets
adaptively queued is the historical values of refs involved in
transactions.
So if you have three concurrent transactions running, and three refs
are involved in two of
On Sunday, October 26, 2014 11:37:43 AM UTC+1, Øyvind Teig wrote:
>
> I have been reading myself up on Clojure concurrency, starting at [1]. In
> [2] I read that
>
> The Clojure STM uses multiversion concurrency control with adaptive
>> history queues for snapshot isolation, and provides a dist
I have been reading myself up on Clojure concurrency, starting at [1]. In
[2] I read that
The Clojure STM uses multiversion concurrency control with adaptive history
> queues for snapshot isolation, and provides a distinct commute operation
but it still needs some explanation to me. Software t
