Creating immutable data and sharing it

Lutger lutger.blijdestijn at gmail.com
Tue Sep 21 11:01:07 PDT 2010


Simen kjaeraas wrote:

> Lutger <lutger.blijdestijn at gmail.com> wrote:
> 
>> Aha, thanks. I have made a conceptual diagram to help understand this,
>> would you
>> care to take a look and confirm whether this is correct or not?
>>
>> 
http://picasaweb.google.com/Lutger.blijdestijn/Illustration#5519337139518828386
>>
>> I hope it explains itself, the edges reflect the types and the nodes the
>> memory
>> storage.
> 
> That looks very much correct. I'm somewhat confused by the 'static data'
> part, as it connected only to one thread, and static data is in TLS, as far
> as I know.

Good, things start falling into places. About the static part, I realized it too 
late, I meant the readonly data (like .rodata) part of the executable where 
string literals and such are dumped. The missing connection was for 
uncluttering.
 
>>> Immutable global state may be instantiated from non-immutable data in
>>> module constructors. I believe that is the canonical way.
>>>
>>
>> Sometimes this is not possible. For example if you want to create a data
>> structure from user input once, then use it read-only for the rest of the
>> program.
> 
> Indeed. In that case, would a shared pointer/array to immutable data work
> for
> you? In such a case, you are free to have local (non-shared) pointers to
> the
> very same data, and thus have no need for locking (which might be needed to
> dereference the shared pointer).

I would love to do something like that:

1. create a thread that makes a complex data structure from user input
2. said thread dies when it is finished, but gives a message back to the parent 
consisting of a pointer to the data that is now cast as immutable.

Now all mutable aliases are destroyed and the program can enjoy doing parellel 
work on the data safely, avoiding any locking. It looks like this is possible.


More information about the Digitalmars-d-learn mailing list