try this once

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • sainath thota

    try this once

    public sealed class singelton
    {
    private static readonly singelton instance;
    private static Object syncroot=new Object();
    private singelton();
    public static singelton instance
    {
    get
    {

    if(instance==nu ll)
    {
    Lock(syncroot)
    {
    if(instance==nu ll)
    instance=new singleton();
    }
    }return instance;

    }
    }
    }
  • Marc Gravell

    #2
    Re: try this once

    There is a very good discussion of Singleton patterns on Jon's site:
    Pobox has been discontinued as a separate service, and all existing customers moved to the Fastmail platform.


    Note that this double-checked/locked approach is exactly the 3rd
    version, which Jon then justifies as "// Bad code! Do not use!"

    Marc

    Comment

    • Mythran

      #3
      Re: try this once



      "Marc Gravell" <marc.gravell@g mail.comwrote in message
      news:uTyJt1Z5IH A.3480@TK2MSFTN GP03.phx.gbl...
      There is a very good discussion of Singleton patterns on Jon's site:
      Pobox has been discontinued as a separate service, and all existing customers moved to the Fastmail platform.

      >
      Note that this double-checked/locked approach is exactly the 3rd version,
      which Jon then justifies as "// Bad code! Do not use!"
      >
      Marc

      One of the comments Jon writes in the 2nd bullet of the 3rd version:

      "I tend to try to avoid situations where experts don't agree what's right
      and what's wrong!"

      Hmm, Jon = expert....does he not agree either/or? Or is he not an expert in
      the 'explicit memory barrier' field? :P

      Mythran


      Comment

      • Marc Gravell

        #4
        Re: try this once

        Or is he not an expert in
        the 'explicit memory barrier' field?  :P
        I think the key point here is that there are people who truly are
        experts in this area (far deeper than language level) who can't agree;
        it doesn't help that part of this is theory (the CLR/CLI spec) rather
        than practice (the MS .NET CLR implementation) , which means you can't
        strictly prove it just by example, because that could be an
        implementation detail. So since it is so easy to work around the
        ambiguity...?

        Marc

        Comment

        • Jon Skeet [C# MVP]

          #5
          Re: try this once

          Mythran <Mythran@commun ity.nospamwrote :
          One of the comments Jon writes in the 2nd bullet of the 3rd version:
          >
          "I tend to try to avoid situations where experts don't agree what's right
          and what's wrong!"
          >
          Hmm, Jon = expert....does he not agree either/or? Or is he not an expert in
          the 'explicit memory barrier' field? :P
          I believe that the version with a volatile field is probably okay.
          However, I don't regard myself as a real expert in this field (or
          virtually any field, to be honest). When people who definitely know
          more than I do disagree, it makes life tricky.

          I *think* that the volatile version is largely regarded as safe, but
          there are lock-free ways of doing it which are more debatable.

          --
          Jon Skeet - <skeet@pobox.co m>
          Web site: http://www.pobox.com/~skeet
          Blog: http://www.msmvps.com/jon_skeet
          C# in Depth: http://csharpindepth.com

          Comment

          Working...