[dmd-concurrency] draft 8: the final countdown

[Michel Fortin]

Le 2010-02-10 à 10:05, Andrei Alexandrescu a écrit :

> I can't believe it's not butter! Draft 8 is the first that completely covers the topics I'd planned. For a good time download:

:-)

I know we already talked about this subject from the last draft, but why do we need atomicOp!"+=" at all? Why not bind += to an atomic operation directly like we do for read and writes? (I'm not asking for the answer to be in the book, I'm just curious about this decision.)


About synchronized classes:

> • Array fields declared declared with type T[] receive type shared(T)[], i.e. the head (the slice limits) is not shared and the tail (the contents of the array) remains shared;
> • Pointer fields declared with type T* receive type shared(T)*, i.e. the head (the pointer itself ) is not shared and the tail (the pointed-to data) remains shared;

As I and other said before, this is totally unhelpful. When I want the referenced to be protected by the lock, assuming it shared will allow it to escape which is *not* safe.

I think it'd be safer to make the referenced value of those fields completely inaccessible. That may sound rash, but it's better than to assume you can do something that should't be allowed. As usual, you can use a cast to bypass the safeties. And if you really want a shared(T)[], you can still write it as shared(T)[].


> To tap into cas-based lock-free goodness, use the shared attribute with a class or struct definition:
> 
> struct LockFreeStruct {
> 	...
> }
> struct LockFreeClass {
> 	...
> }

I think your example lacks 2 'shared', 1 'class' and -1 'struct'.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/