Re: Thread-safety and Singleton methods

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Karl Seguin (_at_)
Date: 01/13/05


Date: Thu, 13 Jan 2005 13:07:50 -0500

This might be useful:

http://odetocode.com/Articles/314.aspx

Reference types, as you say, have their address passed on the stack but
their actual data remains in the heap. However, I don't see this really
being a problem:

Why wouldn't static methods be thread-safe? they apply the same as any
other static method...if you are using static fields (such as the internal
instance of the singleton class) then of course if you change it once it'll
change it everywhere...but if that's a concern, perhaps you aren't using a
singleton properly?

I'm quite confused by your confusion. A static method isn't impacted by the
presence of a singleton...a static function isn't called on an instance of
the class (even if you jsut have one). If the static function is messing
around with the internal static instance,well that' sjust plain silly:

public class SomeClass
   private static SomeClass _instance = new SomeClass();
   public static SomeClass Instance{
      get { return _instance}
   }

  public static void ScrewMeOver(){
       //if you mess with the _instance field in here, you better lock
access
  }
}

perhaps you could provide an example which you think would cause problems?

Karl

-- 
MY ASP.Net tutorials
http://www.openmymind.net/
"Diffident" <Diffident@discussions.microsoft.com> wrote in message
news:8106E28E-DB0F-4A15-9C0D-DC4D2A1D68C3@microsoft.com...
> Guys,
>
> I have been cracking my head over this concept in .NET framework. I have
> read many posts on this topic but not clear about this and hence I am
posting
> it again.
>
> If you have designed your class based on singleton pattern where ONLY ONE
> instance of class exists for the WHOLE APPLICATION DOMAIN....how can the
> public methods in that class be thread-safe? I have read thru posts where
> they say that singleton class methods are thread-safe...I request you to
> justify this conclusion.
>
> How about static methods in singleton class .... are they thread-safe?
>
> Scott Allen informed in one of his posts that:
> ----
> Parameters are passed to a method using a stack. Each thread maintains
it's
> own stack so that the parameters  are not shared among threads.
> ----
>
> How about reference type variables....are they also passed using a stack?
> Reference-types address is stored in the stack and not their values.....so
if
> their addresses are being passed, how come they are thread-safe?
>
>


Relevant Pages

  • Thread-safety and Singleton methods
    ... read many posts on this topic but not clear about this and hence I am posting ... public methods in that class be thread-safe? ... they say that singleton class methods are thread-safe...I request you to ... Parameters are passed to a method using a stack. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Thread-safe fuctions
    ... > a program is reentrant if more than one user can run it ... stronger concept that just "thread-safe". ... data (or does so with the necessary protections), ... > functions to occupy the same position on the stack) ...
    (comp.unix.programmer)
  • Re: Stack and Thread Safety
    ... Stack could have thread unsafe parts in it. ... It's worth pointing out here that "thread-safe" is a rather vague term ... set of tree push operations are atomic. ...
    (comp.lang.java.help)
  • Re: Stack vs heap
    ... pointers will be in the stack too. ... No, in the stack you will never find code, the code is kept somewhere else, ... NEVER create an instance of it, but you use its static methods. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: static fields, methods, properties ... and garbage collection
    ... actually im asking about the static non instance class members. ... and static methods, properties,... ... If im not mistaken on the heap get the GC sweep and mark not the stack ... >> are my static members of a class allocated on the stack and therfore not ...
    (microsoft.public.dotnet.framework.compactframework)