On Thursday, September 29, 2011 04:36 Steven Schveighoffer wrote:On Wed, 28 Sep 2011 17:09:59 -0400, Jonathan M Davis <jmdavisp...@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 >> <jmdavisp...@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 itbeing 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, youend 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
