. NET Framework considerations-thread synchronization-method level

It is about how the framework is considerate to programmers, not C #.

 

This is a subtle effort of the framework on concurrency:

   using System.Runtime.CompilerServices;

Public class myclass
{
[Methodimpl (methodimploptions. Synchronized)]// Considerate?
Public void dosomething ()
{
/* Method code */
}
// Class members
}

This Code uses [methodimpl (methodimploptions. Synchronized)] to implement multi-thread synchronization at the method level.

 

The above code is logically equivalent to the following:

Public class myclass
{
Public void dosomething ()
{
Lock (this) // refer to C # considerations-Lock
{
/* Method code */
}
}
// Class members
}

 

 

What about the two routines? For machines, I guess this is not a problem at all. If I like the fans of AOP, I would naturally think that the first solution is even cooler. The strange thing is that I haven't seen anyone using the first routine in my project, and I use locks without exception. I have always wondered why the result is so one-sided? Does lock look cooler than [methodimpl (methodimploptions. Synchronized?

 

(Press: code source from <programming. NET components> 2nd. Edition Juval Lowy)