thoughts on immutability in D

Peter Alexander peter.alexander.au at gmail.com
Sat Sep 24 19:25:59 PDT 2011


On 24/09/11 4:47 PM, Rainer Schuetze wrote:
> Sorry for the bad example, here's one that is not thread-safe, and where
> the invariant can fail in a multi-threaded environment:
>
> shared(int) globId;
>
> class C
> {
> invariant() { assert((globId & 1) == 0); }
> @property int id() immutable
> {
> globId = globId + 1;
> globId = globId + 1;
> return globId;
> }
> }
>
> But the details whether the operation happens to be thread safe or not
> is irrelevant, thread-safety is not guaranteed by the type system with
> immutable.

It's still thread safe! I think you are misunderstanding what thread 
safety is.

http://en.wikipedia.org/wiki/Thread_safety

You are right in saying that the invariant may break, but that doesn't 
prove that the code isn't thread safe, it just proves that you have a 
bad invariant. You may as well have written:

invariant() { assert(false); }

and then claimed that the code wasn't thread safe because immutable 
didn't save you.

Thread safety in your example simply means that calling id() 10 times 
from different threads will always result in globId == 20 at the end. 
This isn't guaranteed by many languages.

Thread safety does *not* guarantee that your invariant will hold, 
because your invariant not only requires thread safety but mutually 
exclusive access to globId around calls to id().

I should point out that immutable has absolutely no bearing in your 
example. Having immutable methods in a class with no members means 
nothing! The thread-safety comes from the shared(int) here.



More information about the Digitalmars-d mailing list