On Sun, Oct 30, 2011 at 6:20 PM, Ben Franksen wrote:
> According to the original STM paper the implementation does an equality
> test, albeit only for pointer equality.
It strikes me as bad form to depend on characteristics of `the
implementation`.
An incremented integer would probably be ok,
Benjamin Franksen wrote:
> David Barbour wrote:
>> Create an extra TVar Int for every `chunk` in the array (e.g every 256
>> elements, tuned to your update patterns). Read-write it (increment it, be
>> sure to force evaluation) just before every time you write an element or
>> slice it or slice the
David Barbour wrote:
> Create an extra TVar Int for every `chunk` in the array (e.g every 256
> elements, tuned to your update patterns). Read-write it (increment it, be
> sure to force evaluation) just before every time you write an element or
> slice it or slice the array element.
Incrementing a
>
>
> The main question is: does the STM transaction actually "see" that I
> changed
> part of the underlying array, so that the transaction gets re-tried? Or do
> I
> have to implement this manually, and if yes: how?
>
>
The transaction does not detect anything inside the unsafeIOtoSTM. But to
im
On Tue, Oct 25, 2011 at 1:46 PM, Ben Franksen wrote:
> > IME, there are (at least) two possible problems
> > here, 1) transactions scale (quadratically, I think) with the number of
> > TVars touched,
>
> Ouch! What would be the reason for that? I thought it would be linear... I
> mean what happens
Ketil Malde wrote:
> Ben Franksen writes:
>
>> An array of TVars is certainly *much* too inefficient for what I have in
>> mind w.r.t. both memory and cpu time.
>
> You must be a lot more confident than I if you say this without
> benchmarking first. :-)
Ok, not science, but an informed guess
On Tue, Oct 25, 2011 at 1:24 PM, Ketil Malde wrote:
> You must be a lot more confident than I if you say this without
> benchmarking first. :-) IME, there are (at least) two possible problems
> here, 1) transactions scale (quadratically, I think) with the number of
> TVars touched, so if any tran
Ben Franksen writes:
> An array of TVars is certainly *much* too inefficient for what I have in
> mind w.r.t. both memory and cpu time.
You must be a lot more confident than I if you say this without
benchmarking first. :-) IME, there are (at least) two possible problems
here, 1) transactions
David Barbour wrote:
> On Tue, Oct 25, 2011 at 10:47 AM, Ben Franksen
> wrote:
>
>> The main question is: does the STM transaction actually "see" that I
>> changed
>
> part of the underlying array, so that the transaction gets re-tried? Or do
> I
>> have to implement this manually, and if yes: ho
On Tue, Oct 25, 2011 at 10:47 AM, Ben Franksen wrote:
> The main question is: does the STM transaction actually "see" that I
> changed
part of the underlying array, so that the transaction gets re-tried? Or do I
> have to implement this manually, and if yes: how?
>
Create an extra TVar Int for e
As far as I lnow the function 'unsafeIOToSTM' is not transactional in nature
- IO actions will be performed immediately and are not rolled back, and are
then re-performed on retry.
On Oct 25, 2011 12:49 PM, "Ben Franksen" wrote:
> I have an application in mind where concurrent access to large arr
I have an application in mind where concurrent access to large arrays (up to
millions of elements) of mostly small elements (Int or Double) is common.
Typical access patterns would be chunk-wise, i.e. reads or writes from index
n up to index m. Imagine stuff like images, scientific data, etc.
A
12 matches
Mail list logo
