Possible way to achieve lazy loading with const objects

[Steven Schveighoffer]

On Thu, 29 Sep 2011 14:45:24 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> 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.

I can't really see a reason to do this.  It certainly does not sound like  
something we need to cater to.

>
>> > 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.

If all the data the calculated value depends on is immutable, then the two  
threads loading the value at the same time will be loading the same  
value.  If you're writing a 42 to an int from 2 threads, there is no  
deadlock or race issue.  Writing a 42 over a 42 does not cause any  
problems.

-Steve