[dmd-concurrency] draft 7

[Fawzi Mohamed]

I gave a quick reading about the fact that reading needs a lock  
because otherwise it might not be updated almost forever, this is (as  
far as I know) wrong.
Yes the view of one thread might be offset with respect with the one  
of another, but not indefinitely so.
The main reason to put the sync is to ensure that one sees a  
consistent view of the value.
If a value is always updated in an atomic way then the sync is not  
needed.
Well with pointers that address other memory or  80bit reals it is  
another story, but at least for doubles that should be ok, not even a  
barrier is needed.
While you cannot mix atomic updates with locks, if all access are  
atomic you can avoid locks in some places

and now for something completely different, blip.parallel.smp seems to  
pass all my tests even with the new numa aware scheduler, I still  
think that Tasks are a better abstraction to expose to programmers  
than threads, so if anybody wants to take that for a spin...

Fawzi
On 1-feb-10, at 13:07, Andrei Alexandrescu wrote:

> I've entered "synchronized" full speed, but haven't finished (e.g.  
> synchronized constructors aren't yet discussed). New stuff starts  
> around page 21. Please give this a very close read. Thanks.
>
> http://erdani.com/d/fragment.preview.pdf
>
> Walter, you may want to make sure we're on the same page with  
> everything.
>
>
> Andrei
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency