6

I was doing some research inspired by this question and I noticed that several of the proposed solutions to similar problems created a mutex object during initialization of a static variable. Such a mutex will only work as desired if the thread that created it remains alive for the lifetime of the application.

Now it seems a reasonable guess that static variables are initialized by the process main thread, and it also seems a reasonable guess that the process main thread only exits when the main function exits (which is presumably under the control of the programmer).

But are either of these actually guaranteed by the C# language standard?

PS: I'm talking about Windows threads, not .NET threads.

Community
  • 1
  • 1
Harry Johnston
  • 35,639
  • 6
  • 68
  • 158
  • 1
    Your assumption about threads is not right. The main thread can exit before other threads are finished. There was a question about it [here](http://stackoverflow.com/questions/31128935/c-sharp-child-thread-is-still-working-even-main-thread-exit). – GolezTrol Sep 12 '15 at 20:55
  • @GolezTrol: thanks. I don't think that is in itself fatal in this context, because in that example, the main thread exits only because the main function exits. That's under the programmer's control, so we can simply assert that the programmer is responsible for not exiting the main function until it is OK for the mutex to be released. But it still leaves the question of whether the language standard ensures that the main thread won't exit until the main function does. (Question updated accordingly.) – Harry Johnston Sep 12 '15 at 21:23

1 Answers1

3

In C#, static variables are initialized by the class loader when the class is first loaded. This has the interesting artifact of being on whatever thread first referenced the class.

We also note that the main thread is not guaranteed to be a managed thread, so any library after the main thread isn't quite guaranteed to be able to identify it. I wrote a program once that had no main thread after native initialization just to prove it could be done.

Joshua
  • 40,822
  • 8
  • 72
  • 132
  • As I suspected; thanks. Further reading suggests that I should have been thinking not about the main thread but about the UI thread; [I've posted an answer on that basis](http://stackoverflow.com/a/32545751/886887) so if you have time to quickly look it over and let me know if I've made any obvious, horrible mistakes I'd appreciate it. :-) – Harry Johnston Sep 13 '15 at 02:36
  • The UI thread is another misnomer. You can have N UI threads where 0 >= N > (huge number). – Joshua Sep 13 '15 at 22:59
  • I mean the one specified by `Application.Current.Dispatcher` ; that's a constant, isn't it? I wanted to call it "the primary UI thread" but all the documentation appears to just call it "the UI thread" so I figured I should stick with that ... – Harry Johnston Sep 13 '15 at 23:29
  • I don't know anything about WPF. I just know I've made programs where primary UI thread is meaningless (multiple top-level windows). – Joshua Sep 13 '15 at 23:43
  • Yes, I think even in WPF you can have no primary UI thread. I don't think there's a generic solution for all .NET applications, but in the context of that particular question hopefully `Application.Current.Dispatcher` will do. – Harry Johnston Sep 13 '15 at 23:46