Compartilhar via

MethodImplOptions.Synchronized

  • Artigo

>>I just wrote the below but you know what it's 12:17am and I'm suddenly not so sure of anything so tell you what, I'm going to look at the IL tomorrow morning when I get in the office and have had a coffee and I'll update this entry then...

A reader asked about some clarification on the “MethodImplOptions.Synchronized” option as described in Chapter 5 of the Performance and Scalability PAG.

The documentation says:

“Specifies the method can be executed by only one thread at a time.”

And the PAG indicated:

“MethodImplOptions.Synchronized enumeration option. This provides the ability to grant exclusive access to an entire method, which is rarely a good idea.”

However the article by Kit George correctly indentifies that “lock(this)” is used to implement “MethodImplOptions.Synchronized” and further describes why that isn't so useful.

The PAG wording should have been more specific as to how the interlock happens.

I think we should have been more clear that this is one of those ones that goes into the “don't do that” bucket along with the others like “lock(typeof(foo))”

Comments

  • Anonymous
    May 05, 2004
    The comment has been removed
  • Anonymous
    May 05, 2004
    Sadly I just can't get them to stop using "lock(this)" fast enough... so many docs so little time.
  • Anonymous
    May 05, 2004
    There's nothing inherently wrong with lock(this).

    Using lock() on instances of classes that you don't control is what causes problems.

    May be classes that are commonly abused in this way (like colections) should use private lock objects, but even this is not obvious to me.

    Blindly replacing lock(this) with lock(this.privateLockObject) everywhere will just increase the number of allocated objects for no good reason.
  • Anonymous
    May 05, 2004
    The comment has been removed
  • Anonymous
    May 05, 2004
    The comment has been removed
  • Anonymous
    May 05, 2004
    The public member analogy is a good one. Note that the syncblock is essentially a (lazily allocated) public field, and I think this is the real root of the problem.

    For most objects syncblock is not even needed, and when it's needed it could just as well be a separate object that's not accessible from the outside.

    I think you might actually be right. May be it's better to always lock private objects and pretend that lock(this) or the ability to lock arbitrary objects don't exist.

    On the other hand (since this is a performance blog after all) may be storing the lock as part of the object header is better from the locality of reference point of view.
  • Anonymous
    May 05, 2004
    If you allocate the private object that you're going to lock in the .ctor of the object that's doing the locking then they are almost guaranteed to be side-by-side in memory so locality shouldn't be a problem.

    But those are famous last words :)
  • Anonymous
    July 13, 2006
    PingBack from http://mdavey.wordpress.com/2006/07/14/methodimploptionssynchronized/