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>