S
Sherif ElMetainy
Hello
Are these 2 properties (please see below) thead-safe? These properties are
generated in the Resources.cs and Settings.cs files in Visual Studio 2005
(whidbey beta 1).
According to CLI memory model specification
http://dotnet.di.unipi.it/EcmaSpec/PartitionI/cont11.html, Section 11.6.8
"It is explicitly not a requirement that a conforming implementation of the
CLI guarantee that all state updates performed within a constructor be
uniformly visible before the constructor completes. CIL generators may
ensure this requirement themselves by inserting appropriate calls to the
memory barrier or volatile write instructions. "
The first property (ResourceManager) doesn't do any locking at all. Let us
assume that we don't care if 2 instances of the class are created (it will
just be an extra allocation that will be collected shortly, no big deal)
But does the use of the temp variable, prevents the case where the property
can return an uninitialized object if the CLR chooses to perform the
assignment before calling the constructor? Can the CLR also detects that
temp is not used again and perform the assignment directly to _resMgr then
call the constructor?
As for the second property, according to section 4.3 of this document,
http://research.microsoft.com/~birrell/papers/ThreadsCSharp.pdf, this
pattern is not thread safe.
What I want to know is, is this a bug in Visual Studio 2005 beta 1?
Here is the code for the 2 properties:
private static System.Resources.ResourceManager _resMgr;
public static System.Resources.ResourceManager ResourceManager {
get {
if ((_resMgr == null)) {
System.Resources.ResourceManager temp = new
System.Resources.ResourceManager("MyTestLib.Properties.Resources",
typeof(Resources).Assembly);
_resMgr = temp;
}
return _resMgr;
}
}
private static Settings m_Value;
private static object m_SyncObject = new object();
public static Settings Value {
get {
if ((Settings.m_Value == null)) {
System.Threading.Monitor.Enter(Settings.m_SyncObject);
if ((Settings.m_Value == null)) {
try {
Settings.m_Value = new Settings();
}
finally {
System.Threading.Monitor.Exit(Settings.m_SyncObject);
}
}
}
return Settings.m_Value;
}
}
Best regards,
Sherif
Are these 2 properties (please see below) thead-safe? These properties are
generated in the Resources.cs and Settings.cs files in Visual Studio 2005
(whidbey beta 1).
According to CLI memory model specification
http://dotnet.di.unipi.it/EcmaSpec/PartitionI/cont11.html, Section 11.6.8
"It is explicitly not a requirement that a conforming implementation of the
CLI guarantee that all state updates performed within a constructor be
uniformly visible before the constructor completes. CIL generators may
ensure this requirement themselves by inserting appropriate calls to the
memory barrier or volatile write instructions. "
The first property (ResourceManager) doesn't do any locking at all. Let us
assume that we don't care if 2 instances of the class are created (it will
just be an extra allocation that will be collected shortly, no big deal)
But does the use of the temp variable, prevents the case where the property
can return an uninitialized object if the CLR chooses to perform the
assignment before calling the constructor? Can the CLR also detects that
temp is not used again and perform the assignment directly to _resMgr then
call the constructor?
As for the second property, according to section 4.3 of this document,
http://research.microsoft.com/~birrell/papers/ThreadsCSharp.pdf, this
pattern is not thread safe.
What I want to know is, is this a bug in Visual Studio 2005 beta 1?
Here is the code for the 2 properties:
private static System.Resources.ResourceManager _resMgr;
public static System.Resources.ResourceManager ResourceManager {
get {
if ((_resMgr == null)) {
System.Resources.ResourceManager temp = new
System.Resources.ResourceManager("MyTestLib.Properties.Resources",
typeof(Resources).Assembly);
_resMgr = temp;
}
return _resMgr;
}
}
private static Settings m_Value;
private static object m_SyncObject = new object();
public static Settings Value {
get {
if ((Settings.m_Value == null)) {
System.Threading.Monitor.Enter(Settings.m_SyncObject);
if ((Settings.m_Value == null)) {
try {
Settings.m_Value = new Settings();
}
finally {
System.Threading.Monitor.Exit(Settings.m_SyncObject);
}
}
}
return Settings.m_Value;
}
}
Best regards,
Sherif
