[Mono-devel-list] Thread safety of readonly data members?

[gabor]

On Wed, 2004-02-18 at 17:18, Gonzalo Paniagua Javier wrote:
> El mié, 18-02-2004 a las 17:06, gabor escribió:
> > On Wed, 2004-02-18 at 12:49, Jonathan Pryor wrote:
> > > Moving on to Mono, one major problem is that the CLI standard, as
> > > currently specified, uses effectively the same memory consistency model
> > > as Java.  Meaning, C++ techniques such as double-checked locking ARE NOT
> > > VALID:
> > > 
> > > 	private static Class1 foo;
> > > 
> > > 	public static Foo {
> > > 		get {
> > > 			// This will likely work on most platforms, such
> > > 			// as x86, but it is NOT guaranteed to work on 
> > > 			// all potential hardware platforms.
> > > 			if (foo == null) {
> > > 				lock (typeof(Something)) {
> > > 					if (foo == null)
> > > 						foo = new Class1();
> > > 				}
> > > 			}
> > > 		}
> > > 	}
> > > 
> > > In C++, you could use code similar to the above, and you WOULD NOT need
> > > to lock both the class constructor and the accessor methods, as the
> > > calling code ensures that the class has properly constructed before
> > > invoking any member functions.
> > > 
> > > The problem is that double-checked locking isn't really portable in
> > > .NET, so you either need to (a) always lock the code that will construct
> > > the object, or (b) use the static loader lock, described below.
> > 
> > hmmm.. could you explain one more time why is that code wrong?
> >  for example can you give me an example when it goes wrong?
> 
> There's an explanation in
> http://research.microsoft.com/~birrell/papers/ThreadsCSharp.pdf (which
> is listed in http://www.go-mono.com/papers.html).


thanks....phew.... i never EVER thought that something like that could
happen ...
time to forget all the C knowledge :)))

gabor