System.WIndows.Application static members are thread safe?

3
votes

The Application static members are supposed to be thread safe:

The public static (Shared in Visual Basic) members of this type are thread safe. In addition, the FindResource and TryFindResource methods and the Properties and Resources properties are thread safe.1

How much can we trust that statement in a multithreaded environment when calling static member methods of System.Windows.Application?

Update:
It's all in reference to this question: Threading errors with Application.LoadComponent (key already exists)

I never thought I'd see a real bug in the library, but this must be the day for me... that question seems to show a genuine bug. Usually it's "user error," but this doesn't seem to be the case.

2
c#wpfmultithreadingthread-safety
I'd say that you can trust that statement as much as you can trust anything else in the documentation. Is there something specific that you found to be untrue or have a question about? – Jim Mischel
@Jim stackoverflow.com/questions/2463822/… – Kiril

2 Answers

2
votes

This is the general pattern of the .Net framework and associated libraries. Static / Shared members are assumed to be thread safe unless otherwise marked. If you find a member that is not thread safe and is not marked as such in the documentation it is a bug (in either the documentation or implementation).

Therefore I think it's safe to rely on them being thread safe.

1
votes

In general you should trust the documentation at first, but stop trusting it when things don't work as advertised.

In this case the documentation is wrong because of a bug in WPF. See this answer for details about the bug.