I think Greg associated my point to 335; but, specific to your question;
some sort of lock is necessary to block other threads from getting into
the static constructor in order to uphold that guarantee.
It's an implementation detail of the CLR wether using the implicit lock of
the static constructor or an explicit lock is more work; but using a lock
within a static constructor would be more work if what you're trying to
ensure is static member initialization is only done once and that static
member is virtually readonly.
On Sun, 8 Jul 2007 22:46:31 -0500, J. Merrill <[EMAIL PROTECTED]> wrote:
>I'm not questioning the accuracy of your statement, but I don't see a
connection between "static constructors can only be called once"
and "static constructors have an implicit lock." You seem to be saying
that Ron Young's code will work but is doing more work than is necessary
because of the "implicit lock" established by/for the static constructor.
>
>Surely it's possible to implement "only call the static constructor once"
(e.g. with a two-state flag that gets tested and possibly set with an
Interlocked call, and only calls the s.c. if the flag had not been set
previously) without ensuring that the constructor will have completed
execution before another thread (possibly on another processor) that uses
the "run static constructor if not already run" facility (doing "test flag
with Interlocked call / flag is set so don't (re-)run the static
constructor") is able to access a not-yet-initialized value that will very
shortly be set by the static constructor.
>
>Only if the 2nd thread that uses the "run static constructor if not yet
run" facility is stalled until the static constructor is known to be
complete (possibly by having 3 states for the flag, corresponding
to "constructor not yet started", "constructor currently
running", "constructor complete") is there safety without an explicit lock
like Ron Young implemented. Your statement "static constructors have an
implicit lock" suggests that you know that the CLR's implementation does
something like that. Where did you get that information?
>
>Or am I misunderstanding your implication that Ron Young's code is doing
more than is necessary?
>
>At 08:23 PM 7/8/2007, Peter Ritchie wrote
>>Yes, it's thread-safe. Static constructors have an implicit lock (they
>>can only be called once, so other threads must be locked out until the
>>constructor is complete, should it currently be running).
>>
>>You've essentially implemented a singleton...
>>
>>-- Peter
>>
>>On Sun, 8 Jul 2007 18:00:19 -0500, Ron Young <[EMAIL PROTECTED]>
>>wrote:
>>
>>>Say I have this class, I'm copying/pasting from Visual Studio:
>>>
>>> class StaticObject_VariableHolder
>>> {
>>> private static object _sharedVariable;
>>> private static object _syncRoot = new object();
>>>
>>> private StaticObject_VariableHolder()
>>> {
>>> }
>>>
>>> public static object SharedVariable
>>> {
>>> get
>>> {
>>> if (_sharedVariable == null)
>>> {
>>> lock (_syncRoot)
>>> {
>>> if (_sharedVariable == null)
>>> {
>>> _sharedVariable = new object();
>>> }
>>> }
>>> }
>>>
>>> return _sharedVariable;
>>> }
>>> }
>>> }
>>>
>>>And I read this article,
>>>http://msdn.microsoft.com/msdnmag/issues/05/08/Concurrency/
>>>
>>>Is the following equivalent as above in regards to a one-time
>>initialization
>>>of a shared variable that is publicly (statically) accessible:
>>>
>>>
>>>
>>> /// <summary>
>>> /// From http://msdn.microsoft.com/msdnmag/issues/05/08/Concurrency/
>>> /// on "What Memory Needs Lock Protection"
>>> /// "Second; memory that is read-only after publication does not
need
>>a
>>>lock
>>> /// because any invariants associated with it must hold for the
>>program
>>> /// (since the value does not change).
>>> /// </summary>
>>> /// <typeparam name="T"></typeparam>
>>> class BaseProvider<T>
>>> {
>>> private static readonly T _sharedObject;
>>>
>>> public static T SharedObject { get { return _sharedObject; } }
>>>
>>> static BaseProvider()
>>> {
>>> _sharedObject = default(T);
>>> }
>>> }
>>>
>>>It's not that we need BaseProvider to be singleton - although it could
>>be -
>>>but just access to it's shared variable.
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
