static constructor

[Marek]

Hi,

I am analyzing Duwamish7 source code boundled with Visual Studio .NET 2003.
Could anoybody explain why the Monitor.Enter and Monitor.Exit block is used
inside a static constructor? The code can be found in Project
SystemFramework within module ApplicationLog.cs. Here comes the sample.

namespace Duwamish7.SystemFramework {

(some code...)

public class ApplicationLog {
(some code..)
static ApplicationLog() {
Type myType = typeof(ApplicationLog);
try {
if (!Monitor.TryEnter(myType)) {
Monitor.Enter(myType);
return;
}
(some code..)
}
finally {
Monitor.Exit(myType);
}

} // static constructor

} // class ApplicationLog

(some code..)

} //namespace Duwamish7.SystemFramework
namespace Duwamish7.SystemFramework {

(...)

public class ApplicationLog {

Type myType = typeof(ApplicationLog);


try {

if (!Monitor.TryEnter(myType)) {

Monitor.Enter(myType);

return;

}

(...)

Thank you in advance.

Mark

 

[Marek]

The code in my post should look like this:

namespace Duwamish7.SystemFramework {

(some code...)

public class ApplicationLog {
(some code..)
static ApplicationLog() {
Type myType = typeof(ApplicationLog);
try {
if (!Monitor.TryEnter(myType)) {
Monitor.Enter(myType);
return;
}
(some code..)
}
finally {
Monitor.Exit(myType);
}

} // static constructor

} // class ApplicationLog

(some code..)

} //namespace Duwamish7.SystemFramework

 

[Scott Allen]

I don't think this is a very good example to follow, Markek. I don't
see why a Monitor is useful here at all. Also, it's a bad idea to lock
on a type object, Microsoft has been attempting to scrub this practice
out of the examples.Locking on a type is a very coarse lock on an
object that is expensive to create, and anyone inside the app domain
(even out) can aquire the type object and take a lock, which opens up
the potential for deadlock.

 

[Marek]

Hi Scott,

Thank you for your explanation but there's still something that I don't
understand.
Please listen to the following and point where I make a mistake.

1. Static constructor (SC) is guaranteed to be executed not more then once
(isn't it?).
2. If a class contains only static methods (which is the case) SC is
executed (implicite) BEFORE the first call to a static method.
3. That means that SC code cannot interfere (i.e. be executed
simultaneously) with any other static method code.
4. As a result, there's no need to protect execution of SC against
multithreading safety.

Helper question. Is it possible the a static method (let's say in another
thread) starts its execution before the execution of static constructor
ends?

Thanks
Marek

 

[Scott Allen]

Hi Marek:

The static constructor will execute only once.

If we assume the lock inside of the constructor is only for the
purpose of protecting the static constructor from concurrent access,
we could say the lock is not needed. But, we don't know where else
this lock might be used, because some other code might lock on
typeof(ApplicationLog). Perhaps the lock is trying to protect some
other resource the static constructor touches. Thus, this code is not
a great example to look at, particularly in isolation.

--s

 

[Marek]

Hi Scott

The only thing that I've been trying to find out is whether this code is a
piece of shit or a very advanced technique to achieve something.

I have to ask what do you mean by saying "the lock is trying to protect some
other resources the static constructor touches"?
How can putting a lock on typeof(ApplicationLog) protect anything else but
the type class instance itself? Are you sure you didn't make mistake in what
you said?

Marek

 

[Marek]

OK. I understand now.
Other class' methods can also put a lock on typeof(ApplicationLog) before
the static constructor starts its execution.
Thus, in some cases putting a lock inside a static constructor can be
reasonable.

Thank you.
Marek