Simen kjaeraas wrote: > Lutger <[email protected]> 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.
