Possible way to achieve lazy loading with const objects

Jonathan M Davis jmdavisProg at gmx.com
Thu Sep 29 11:45:24 PDT 2011


On Thursday, September 29, 2011 04:36 Steven Schveighoffer wrote:
> On Wed, 28 Sep 2011 17:09:59 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > On Wednesday, September 28, 2011 13:56 Steven Schveighoffer wrote:
> >> On Wed, 28 Sep 2011 16:03:51 -0400, Jonathan M Davis
> >> <jmdavisProg at gmx.com>
> >> 
> >> wrote:
> >> > On Wednesday, September 28, 2011 11:31:31 Christophe wrote:
> >> >> "Jonathan M Davis" , dans le message (digitalmars.D:145479), a écrit
> >> >> 
> >> >> > But since lazy initializion will _never_ work with immutable
> >> >> 
> >> >> Never say never. One could build a clean and thread-safe way to
> >> 
> >> lazily
> >> 
> >> >> initialize fields. Like someone said, even without mutex, if the
> >> >> function to compute the variable is pure and based on immutable data,
> >> >> the worst case would be to run the intializing function twice. And
> >> 
> >> the
> >> 
> >> >> langage could include mutexes to do prevent that to happen. The fact
> >> >> that immutable data could, one day, be put in ROM doesn't mean that
> >> 
> >> it
> >> 
> >> >> has to. The close issue is like another-one said the issue of
> >> >> memoization of pure methods.
> >> > 
> >> > The very fact that an immutable variable _could_ be put into ROM
> >> 
> >> negates
> >> 
> >> > the
> >> > possibility of the semantics being such that you don't have to fully
> >> > initialize an immutable variable up front.
> >> 
> >> No it doesn't. If it's in ROM, initialize eagerly (which should cost
> >> nothing, done at compile-time). If it's not, initialize lazily.
> > 
> > That's assuming that objects can only ever be put into ROM at compile
> > time. Is
> > such an assumption valid? And not just currently valid, but permanently
> > valid?
> 
> By definition ROM is read only. How can it be created during runtime if
> it's read-only? And if it's some hardware-based ROM, what makes it
> read/write during the constructor?

I don't know. I'm not an expert on ROM. The main place that I've heard it 
being discussed as being actually used in D is the place in the program where 
the string literals go on Linux. But from the descriptions and explanations of 
immutable, it's always sounded to me like the compiler could choose to put 
something in ROM at runtime (which I guess would be more like WORM than ROM). 
So, I may be completely misunderstanding something about what could even 
thereotically be done by the compiler and ROM.

> > Though I suppose that even if that assumption isn't valid, the compiler
> > should
> > still know when it's putting something in ROM and force eager loading it
> > that
> > case.
> > 
> > However, that does introduce the whole locking issue again, since
> > immutable
> > variables are implicitly shared.
> 
> Locking issues are not present when all the data is immutable. It's why
> immutable is implicitly shared.

But locks _are_ an issue if you're doing lazy loading with immutable as you've 
suggested. The only way to do lazy loading that I'm aware of is to have a flag 
that says whether the data has been loaded or not. That flag is going to have 
to be changed from false to true when the loading is done, and without a lock, 
you could end up with two threads loading the value at the same time. So, you 
end up with a locking.

- Jonathan M Davis


More information about the Digitalmars-d mailing list