Page 9 of 14 FirstFirst ... 6789101112 ... LastLast
Results 81 to 90 of 132
  1. #81

    Default

    Quote Originally Posted by kamsky View Post
    Problem: A thread instantiate a singleton, while it's not done instantiating, another thread instantiate the same singleton class. Now they are two instances.

    So how do you ensure single instance in a Singleton in a multi-threaded environment?
    lots of way to do that, you can use locks if you want.

    you can declare the entire class as static

    c#

    or you can do something like this cuz im lazy:

    Code:
    class Singleton {
     static readonly Singleton instance=new Singleton();
     
     Singleton() {
     }
    
     public Singleton Instance {
      get {return instance; }
     }
    }

  2. #82

    Default

    how do you do locks without too much overhead?

  3. #83

    Default

    Quote Originally Posted by kamsky View Post
    how do you do locks without too much overhead?
    murag case to case yan bro...

    meron ba overhead ang locking? or the entire thread mechanism? coz "locking" works at speed of nanoseconds (imagine how fast to lock an object ) mas overhead ang locking object with blocking/switching/sleep/waiting of threads coz it will cost you around microseconds...


    in windows environment ang scheduling sa thread is at milliseconds. So medyo may point ka, coz improper locking and unlocking of objects without the knowledge of thread scheduling/cycles will give you overhead, especially if there are multiple child threads waiting, that implements chain of responsibility when some thread can lock and the other thread can unlock also...so from here, overtime/overhead may occur, worst case Deadlock!

    again, its case to case basis, especially if how/where/when you implement locking,, better to have some sort of sample program to base our discussion.

  4. #84

    Default

    Mark,

    Im sure you dont do 'lock' if you dont have these waiting/sleeping/blocking issues.
    So what i meant the overall synchronization of multiple threads that trying to access a concurrent object. Even so acquiring and releasing locks regardless how short it is has an overhead than normal..

    here's an example for singleton that is multi-threaded safe but needs optimization:

    Code:
    public class Singleton {
       private static Singleton instance = null;
       
       // this is already a threadsafe for multi-threaded envs, 
       // but synchronized is an overhead
       // and you dont really need this all the time since 
       // initialization of the instance is just happening once
       public synchronized static Singleton getInstance()  {
           if (instance == null) {
             instance = new Singleton();       
           }       
           return instance;
       }
     
    }

  5. #85

    Default

    Quote Originally Posted by kamsky View Post
    Problem: A thread instantiate a singleton, while it's not done instantiating, another thread instantiate the same singleton class. Now they are two instances.

    So how do you ensure single instance in a Singleton in a multi-threaded environment?
    Basically, objects are just like structs or variables in C. It's just a region in memory that is allocated by your program. When two threads instantiate a singleton, they simply refer to the same region in memory. The exact location is implementation-dependent. It may be located in the heap or whatever...

  6. #86

    Default

    @silent-kill

    I like that 'readonly' keyword. We dont have that in Java. Let me check on that, maybe time to change career?

  7. #87

    Default

    Quote Originally Posted by simoncpu View Post
    Basically, objects are just like structs or variables in C. It's just a region in memory that is allocated by your program. When two threads instantiate a singleton, they simply refer to the same region in memory. The exact location is implementation-dependent. It may be located in the heap or whatever...
    I understand that bro but how do you ensure that you just initialiaze the singleton once. On startup, there might be two threads initialiazing two objects in the same class in just lightning speed.


    PS.
    yes this can be solved through synchronization/locking but need more optimization. See my previous post.

  8. #88

    Default

    Quote Originally Posted by kamsky View Post
    @silent-kill

    I like that 'readonly' keyword. We dont have that in Java. Let me check on that, maybe time to change career?
    wakkkk wag bro... hehehehe.. bitaw, I know ur just kidding, wala ba constant delcaration ang java? same ra man na sa C#, nasa runtime lang. check also "final" keyword in java, whether if it is at compile or runtime.

  9. #89

    Default

    as for the optimization part it actually depends on what you are trying to implement. there are cases when its more 'optimize' to implement it in multi-threaded there are also cases where in the next process is dependent on the previous result. etc etc

    with this i will probably use 'worker' threads... and have a 'pool/queue' of tasked that needs to be consumed by the 'worker' threads.. it also depends on the machine on how many core it has on how many threads it can actually work on effectively.


    another pattern i see useful is a Decorator

  10. #90

    Default

    Quote Originally Posted by kamsky View Post
    Mark,

    Im sure you dont do 'lock' if you dont have these waiting/sleeping/blocking issues.
    So what i meant the overall synchronization of multiple threads that trying to access a concurrent object. Even so acquiring and releasing locks regardless how short it is has an overhead than normal..

    here's an example for singleton that is multi-threaded safe but needs optimization:

    Code:
    public class Singleton {
       private static Singleton instance = null;
       
       // this is already a threadsafe for multi-threaded envs, 
       // but synchronized is an overhead
       // and you dont really need this all the time since 
       // initialization of the instance is just happening once
       public synchronized static Singleton getInstance()  {
           if (instance == null) {
             instance = new Singleton();       
           }       
           return instance;
       }
     
    }



    Forgive my ignorance in JAVA, but I will try to understand your code above.


    How is this "synchronized" mechanism in JAVA? The standard procedure/process, under Virtual Machine or equivalent CLR in .NET?


    How about wrapping this via property getter? Coz another thing I notice is the keyword "static", in .NET environment, all static are loaded and initialized directly at runtime. I don't in know in JAVA. Isn’t it thought that your singleton class should initialize only at the time you need them? What happen if we apply a singleton class that categorize for printing documents? At the time the user will run our application, we already loaded the singleton class even though we are not sure that our application will make use of it. This is the same on the print spooler in windows system.


    The problem here is that the method itself was synchronized, and this method is seems to be constructor of your singleton class? (Am I right?), you wanted to instantiated the class provided that it can only happen once, in a thread safe manner.


    To summarized the situation:


    PREVIOUS SOLUTION:


    Thread(1), Thread(2), Thread(3), Thread(4), Thread(5)


    All of them are independent to each other; all of them are allowed to instantiate our singleton class. Applying “synchronization” solves the issue in this scenario where ex. “thread (3)” is currently writing values to some attributes of our instance of singleton class after instantiating it. So whatever threads want to access later on, we can assure that they have the same shared value. Drawback is, we are doing repeatedly with the synchronized mechanism.


    OTHER SOLUTION:



    Implement a Parent and Child thread using pthreads in c++, or BackgroundWorker in C#.NET, a child thread will be spawned to instantiate and notify the parent thread, that our singleton class has already been instantiated. The beauty of this, we don’t have to worry about synchronizing the main thread… The only thing we do is to block the parent thread at the time when one of our child thread signals to instantiate the singleton class. KILL the child’s thread… we don’t need it anymore; the instantiated singleton class is already on the MEMORY.


    Try to check what’s the equivalent on PThreads or BGWorker or ThreadPool (commonly known as Thread local storage)

Page 9 of 14 FirstFirst ... 6789101112 ... LastLast

Similar Threads

 
  1. what's the best and most practical NEGOSYO today?????
    By fratbaxxx in forum Business, Finance & Economics Discussions
    Replies: 166
    Last Post: 10-09-2014, 01:31 PM
  2. Looking For: Pattern makers, Seamstresses and Tailors
    By kamikaze_007 in forum Jobs
    Replies: 5
    Last Post: 06-02-2013, 10:47 AM
  3. Replies: 0
    Last Post: 09-14-2007, 10:14 AM
  4. Replies: 0
    Last Post: 06-21-2007, 11:01 AM
  5. Bad design and coding practices (antipatterns)
    By cmontoya in forum Programming
    Replies: 8
    Last Post: 01-05-2006, 06:31 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
about us
We are the first Cebu Online Media.

iSTORYA.NET is Cebu's Biggest, Southern Philippines' Most Active, and the Philippines' Strongest Online Community!
follow us
#top