none
Why static members are called Threadsafe in MSDN?

    Question

  • Hello,

    For almost each class we can read following line in MSDN under thread safety section.


    Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

    Can anybody please explain this line in depth. My concern is with static types. They say that it is thread safe but what is that mechanism inside CLR that makes static members thread safe? And suppose I am taking one static object and I am sharing it between the threads then operations on this object from different threads can be done without locking mechanism? I need not use lock in this scenario? If yes then how CLR manages synchronization for different threads using this static member? If No then why static object is said to be thread safe in above line of MSDN. And What does MSDN mean by threadsafety or which scenarios are covered under threadsafety.

    If I have posted it on wrong thread then sorry but I think understanding this line can clear many concepts.

    Thanks and Regards,
    Vishal
    Thursday, July 30, 2009 6:07 AM

Answers

  • Don't take any stock in that.  It's a boilerplate line that got copied and pasted into every class documentation in the MSDN library.  Including classes that have no static members, the vast majority of all .NET classes, and classes that have static members but that are not in fact thread-safe.  Control.CheckForIllegalCrossThreadCalls is static but not thread-safe for example.

    The only real way to make a field thread-safe is to declare it readonly.  There is no hidden magic in the CLR that makes a writable member safe.  Microsoft Research is experimenting with software transactional memory, that's a step in the direction of real thread-safe data.  For now, you can safely assume that nothing is safe in the framework, other than the new and lock keywords.  Which is in fact quite an asset, there have been many wrong-headed approaches to safety in the past.  We'll forgive them for the Synchronized method.



    Hans Passant.
    Thursday, July 30, 2009 11:19 AM

All replies

  • It´s a very interesting issue.
    If you want, read this to get a deeper prespective.


    Please mark posts as answers/helpful if it answers your question
    Thursday, July 30, 2009 10:38 AM
  • Hello Andoni,

    First of all thanks for your reply.

    It is a nice artical. I will go through it.

    But I want to know what MSDN wants to specify by the line --

    Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

    Thanks and Regards,
    Vishal
    Thursday, July 30, 2009 10:59 AM
  • Don't take any stock in that.  It's a boilerplate line that got copied and pasted into every class documentation in the MSDN library.  Including classes that have no static members, the vast majority of all .NET classes, and classes that have static members but that are not in fact thread-safe.  Control.CheckForIllegalCrossThreadCalls is static but not thread-safe for example.

    The only real way to make a field thread-safe is to declare it readonly.  There is no hidden magic in the CLR that makes a writable member safe.  Microsoft Research is experimenting with software transactional memory, that's a step in the direction of real thread-safe data.  For now, you can safely assume that nothing is safe in the framework, other than the new and lock keywords.  Which is in fact quite an asset, there have been many wrong-headed approaches to safety in the past.  We'll forgive them for the Synchronized method.



    Hans Passant.
    Thursday, July 30, 2009 11:19 AM
  • Hello,

    Thank you for your reply. Now it is cleared for me. "There is no hidden magic in the CLR that makes a writable member safe." -- this line says everything.

    Should Microsoft correct that threadsafety line which we can see everywhere in MSDN?

    Regards,
    Vishal
    Thursday, July 30, 2009 11:53 AM
  • Can you speak more about this? I would think that methods like System.Threading.Monitor.Enter and ....Exit, etc. are threadsafe, as well as many methods on System.Threading.Semaphore, etc.

    What do you mean by "Synchronized method"? Are you talking about

    System.Runtime.CompilerServices.MethodImplOptions.Synchronized

    ?


    In Christ, Aaron

    Tuesday, July 31, 2012 4:38 PM