So dmd-cc. Whats your opinion on an optimistic concurrency? Heavy exlusive transactions on not allways ideal but an optimistic based approach allows more computation to just keep on running.

This sort of approach which is sometimes called STM (software transactional memory) can crunch a whole lot more numbers if we think "this lock is probably not in use by anyone else, just go for it":

1) Save a copy/hash of the computations dependencies (arguments to functions
that are passed by ref)
2) Do the computation.
3) If dependencies have changed go to step 1 else commit.

If such algorithms were implemented they should preferably be made implicit with algorithms generic enough for handling any kind of arguments, rolling back etc. If the function doesn't modify any state other than the target result then this could reduce complexity a lot but not necessarily impossible to do with other styles.

I'm not sure if the semantics of D's current pure function implementation could be the base of such algorithms but how much of a speedup is the current D pure optimizations giving us anyway?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100107/7f98ef3e/attachment.htm>

Tim Matthews wrote:
> So dmd-cc. Whats your opinion on an optimistic concurrency?

If you just joined the list, STM has just been briefly discussed. You may want to peruse the archives at http://lists.puremagic.com/pipermail/dmd-concurrency/2010-January/thread.html.

Andrei

On Fri, Jan 8, 2010 at 1:27 AM, Andrei Alexandrescu <andrei at erdani.com>wrote:

> Tim Matthews wrote:
>
>> So dmd-cc. Whats your opinion on an optimistic concurrency?
>>
>
> If you just joined the list, STM has just been briefly discussed. You may want to peruse the archives at http://lists.puremagic.com/pipermail/dmd-concurrency/2010-January/thread.html .
>
>
Just joined because it has only recently been created (less than a week old). Any particular thread because none talk about stm as the sole subject.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100108/d5064747/attachment.htm>

You might want to read about STM here:

http://www.bluebytesoftware.com/blog/Default.aspx#a4cfad7df-ed84-46a4-a961-54aafdaeb9d7

Essentially, it's a technology with too many fundamental problems.


Tim Matthews wrote:
> So dmd-cc. Whats your opinion on an optimistic concurrency? Heavy exlusive transactions on not allways ideal but an optimistic based approach allows more computation to just keep on running.
>
> This sort of approach which is sometimes called STM (software transactional memory) can crunch a whole lot more numbers if we think "this lock is probably not in use by anyone else, just go for it":
>
> 1) Save a copy/hash of the computations dependencies (arguments to
> functions that are passed by ref)
> 2) Do the computation.
> 3) If dependencies have changed go to step 1 else commit.
>
> If such algorithms were implemented they should preferably be made implicit with algorithms generic enough for handling any kind of arguments, rolling back etc. If the function doesn't modify any state other than the target result then this could reduce complexity a lot but not necessarily impossible to do with other styles.
>
> I'm not sure if the semantics of D's current pure function
> implementation could be the base of such algorithms but how much of a
> speedup is the current D pure optimizations giving us anyway?
> 

On Sun, Jan 10, 2010 at 9:43 PM, Walter Bright <walter at digitalmars.com>wrote:

> You might want to read about STM here:
>
>
> http://www.bluebytesoftware.com/blog/Default.aspx#a4cfad7df-ed84-46a4-a961-54aafdaeb9d7
>
> Essentially, it's a technology with too many fundamental problems.
>
>
Long read but doesn't explain why certain options got the complete thumbs down from an early point & not quite what I had in mind anyway. I do agree with pretty much everyone's need of message passing as a must have. It is clearly safer than many other alternatives. But I think at times other options although not better overall could be explored as they may well suit particular jobs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100111/cb4bb1a8/attachment.htm>