You only asked one question here but there are a dozen or so questions that you should have asked, so I'll answer them all.
Here is the sequence which I assumed
- Start of class constructor (also known as
cctor
)
- End of cctor
- start of Main
- start of MyMethod
Is this correct?
No. The correct sequence is:
- Start of cctor for Program, if there is one. There is not.
- End of cctor for Program, if there is one. There is not.
- Start of Main
- Start of cctor for MyClass
- End of cctor for MyClass
- Start of MyClass.MyMethod
What if there is a static field initializer?
The CLR is permitted to change the order in which static field initializers run in some cases. See Jon's page on the subject for details:
The differences between static constructors and type initializers
Is it ever possible for a static method like MyMethod
to be called before the cctor of that class completes?
Yes. If the cctor itself calls MyMethod then obviously MyMethod will be called before the cctor completes.
The cctor does not call MyMethod. Is it ever possible for a static method like MyMethod
to be called before the cctor of MyClass completes?
Yes. If the cctor uses another type whose cctor calls MyMethod then MyMethod will be called before the MyClass cctor completes.
No cctors call MyMethod, directly or indirectly! Now is it ever possible for a static method like MyMethod
to be called before the cctor of MyClass completes?
No.
Is that still true even if there are multiple threads involved?
Yes. The cctor will finish on one thread before the static method can be called on any thread.
Can the cctor be called more than once? Suppose two threads both cause the cctor to be run.
The cctor is guaranteed to be called at most once, no matter how many threads are involved. If two threads call MyMethod "at the same time" then they race. One of them loses the race and blocks until the MyClass cctor completes on the winning thread.
The losing thread blocks until the cctor is done? Really?
Really.
So what if the cctor on the winning thread calls code that blocks on a lock previously taken by the losing thread?
Then you have a classic lock order inversion condition. Your program deadlocks. Forever.
That seems dangerous. How can I avoid the deadlock?
If it hurts when you do that then stop doing that. Never do something that can block in a cctor.
Is it a good idea to rely upon cctor initialization semantics to enforce complex security requirements? And is it a good idea to have a cctor that does user interactions?
Neither are good ideas. My advice is that you should find a different way to ensure that the security-impacting preconditions of your methods are met.