Re: lock(...) question
From: Alvin Bruney [MVP] (vapor)
Date: 02/02/05
- Next message: Rob R. Ainscough: "Is CrystalReports part of the .NET framework v1.1 ?"
- Previous message: Juan: "Remoting and autosubscription"
- In reply to: Yunus Emre ALPÖZEN: "Re: lock(...) question"
- Next in thread: Jon Skeet [C# MVP]: "Re: lock(...) question"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 2 Feb 2005 13:07:36 -0400
> This will prevent creating instance twice.... Is it clear ?
no, it is not clear. the second thread will simply get a reference to the
singleton object of thread A.
The first null check simply avoids the overhead of a lock as you rightly
pointed out. Otherwise, you have a situation where you lock just to read a
variable that
may or may not be null which is needlessly expensive. You test the reference
again for safety inside the critical section since the examining thread is
the only thread that holds a reference to
the object inside an executing application domain. You would need a stronger
lock (mutex etc) if the singleton reference were exposed to multiple
processes or app domains.
-- Regards, Alvin Bruney [MVP ASP.NET] [Shameless Author plug] The Microsoft Office Web Components Black Book with .NET Now Available @ http://tinyurl.com/27cok ---------------------------------------------------------- "Yunus Emre ALPÖZEN" <yemre@msakademik.net> wrote in message news:ukMFSRUCFHA.3728@TK2MSFTNGP14.phx.gbl... > Just think. Two thread wants to get an instance of your singleton class. > One thread comes and locks m_syncRoot and starts to create instance. At > this time another thread has came and second one also wants to lock. And > it will wait for the first thread. After first thread releases m_syncRoot. > Second one is allowed to lock m_syncRoot. At that time there is an > instance of singleton class. > > This will prevent creating instance twice.... Is it clear ? > > -- > Thanks, > Yunus Emre ALPÖZEN > > > > "wh1974" <wayne@pyesmeadow.com> wrote in message > news:1107360873.456370.21160@o13g2000cwo.googlegroups.com... >> Just wondering whether somebody could clarify my understanding on some >> code I've seen several times over the past week: >> >> if (m_instance == null) >> { >> lock (m_syncRoot) >> { >> if (m_instance == null) >> { >> m_instance = new Singleton(); >> } >> } >> } >> >> I have no problem understanding what the code is doing but I fail to >> understand the reason for comparing m_instance to null twice. >> >> Surely the following is equivalent: >> >> lock (m_syncRoot) >> { >> if (m_instance == null) >> { >> m_instance = new Singleton(); >> } >> } >> >> Is it just a case of avoiding the call to lock(...) to improve >> performance? >> >> Thanks, >> Wayne. >> > >
- Next message: Rob R. Ainscough: "Is CrystalReports part of the .NET framework v1.1 ?"
- Previous message: Juan: "Remoting and autosubscription"
- In reply to: Yunus Emre ALPÖZEN: "Re: lock(...) question"
- Next in thread: Jon Skeet [C# MVP]: "Re: lock(...) question"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
