Skipping locked section already in use
-
And you don't; nor does it need to be a Singleton. It can be a static field of the class, for instance.
Yes, but that would cause unneccesary coupling. I'm not suggesting singletons are absolutely necessary (heck even
while,for,switchandcontinuestatements aren't!). My point is the singleton pattern (especially when combined withLazy<T>) allows one to write more performant and more manageable code. /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Yes, but that would cause unneccesary coupling. I'm not suggesting singletons are absolutely necessary (heck even
while,for,switchandcontinuestatements aren't!). My point is the singleton pattern (especially when combined withLazy<T>) allows one to write more performant and more manageable code. /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Ravi Bhavnani wrote:
that would cause unneccesary coupling.
I don't think so.
Ravi Bhavnani wrote:
one to write more performant and more manageable code.
Bullpuckey.
-
Pete O'Hanlon wrote:
The biggest problem with singletons lies in the fact that it reduces parallelism. As you only have a single instance present, any threaded operations must be serialized in and out of the singleton, reducing the efficiency of the threading. They can also make it harder to unit test code because it can introduce global state.
I don't agree. The biggest problem with singletons is incorrect usage and from that overusage. For your points... For the first problem sometime the very nature of the need dictates serialization anyways. And in other cases there are ways that can allow multiple access. As for the second problem there are trivial solutions for most problems of that nature, for example just implementing a Reset() method.
jschell wrote:
For the first problem sometime the very nature of the need dictates serialization anyways.
In that case, you shouldn't be parallelising the code at this point. This concern was raised specifically for the case where you have a parallel architecture that has to be throttled because of a singleton.
jschell wrote:
As for the second problem there are trivial solutions for most problems of that nature, for example just implementing a Reset() method.
So, we're talking about introducing a method just to get through a test; not for any other purpose. I think you misunderstood my point. I wasn't arguing that you should never use a singleton; I was just showing what the weaknesses are. If you are comfortable that you understand the pattern sufficiently well, and that you know exactly how your code is going to be used, then you can make an informed decision. If you don't know what the weaknesses are, then you can end up causing all sorts of problems for yourself.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
-
Sentenryu wrote:
all of those threads run in the App Domain of the console application
Oh, yes, but then why do you have threads?
Sentenryu wrote:
the console application
The main method of which is static already, so I'd likely stick with static. Hmmm... so, if I understand what you're saying, each client makes a connection to the Server and gets its own thread, which I suppose is a session, and it continues to interact with the server that way until it disconnects? I'm not sure that's a good architecture*, but not being an expert on that sort of thing, I'd better keep quiet and let others provide guidance. * I'm fairly sure that a "connectionless" technique is more robust.
i'm just very bad in English =p there's no logical connection from the client to the server, the client just sends a request and the server responds, after the response, there's no more link between the client and the server, the threads are used so the server can serve more than one client at a time.
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
-
i would like to hear more about why singleton are silly... I've a case where a server application would manage a list of users, the server could add a user,
getLoggedUsers, log a user in, log out a user, get a list of all users and contact one user to send a chat request (the client contacts the server about the chat request, the server alerts the target user and then the users would chat directly), to implement the functionality of the contacts list (not a simple List, sadly) i've made a static class who controls the underling List, synchronizing it with a XML file (used to serialize the list), this way, all the users contacting the server would see the same list of users. i was thinking in replacing the static class with a singleton, you think it's a bad idea? i would appreciate your opinion.I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
They artificially restrict your ability to change your mind later, and don't really provide any benefit. You can always just instantiate one copy of an object if you only need one! If you have a need for a single static instance of some stuff, have a static reference to it.
static class GlobalData {
public static ContactListManager ContactListManager { get; private set; }static GlobalData(){
ContactListManager = new ContactListManager("datastore.xml");
}
}That way, if you discover that you want to manage disparate contacts across several data sources and therefore it shouldn't be a singleton any more, it's much easier to change. It means that if you want a temporary separate instance for some reason (e.g. importing external data), you can do so.
-
PIEBALDconsult wrote:
make it a Singleton? Why?
For performance reasons. I would prefer to not have to
newup a concreteIPrettyPrinterRuleProvidereach time I callPrettyPrinter.PrettyPrint(). /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Ravi Bhavnani wrote:
For performance reasons. I would prefer to not have to
newup a concreteIPrettyPrinterRuleProviderThere is design, implementation and performance. Distinct but interrelated idioms. You would NEVER impose a design limit based solely on creating an instance. You MIGHT impose a design limit based on the work that creating an instance requires. That however is very, very rare. (I am specifically referring to creating the instance.) And I suspect for your example it does not apply. In terms of measuring (actual values) the performance of an application if you find that a specific bit of code imposes a performance bottleneck on the application (not a just a hunk of code) then you modify the implementation to correct that. If you must modify the design to correct a measured performance problem then you have a bug in the design which requires a rework of the design and implementation. The factors the lead to a redesign where the ONLY problem is a performance problem is probably very rare. Typically if someone cannot anticipate a performance problem at the design level then the design is incomplete or the designer does not have enough experience and thust the entire design is questionable.
-
jschell wrote:
For the first problem sometime the very nature of the need dictates serialization anyways.
In that case, you shouldn't be parallelising the code at this point. This concern was raised specifically for the case where you have a parallel architecture that has to be throttled because of a singleton.
jschell wrote:
As for the second problem there are trivial solutions for most problems of that nature, for example just implementing a Reset() method.
So, we're talking about introducing a method just to get through a test; not for any other purpose. I think you misunderstood my point. I wasn't arguing that you should never use a singleton; I was just showing what the weaknesses are. If you are comfortable that you understand the pattern sufficiently well, and that you know exactly how your code is going to be used, then you can make an informed decision. If you don't know what the weaknesses are, then you can end up causing all sorts of problems for yourself.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
Pete O'Hanlon wrote:
In that case, you shouldn't be parallelising the code at this point. This concern was raised specifically for the case where you have a parallel architecture that has to be throttled because of a singleton.
Not sure what you are referring to. I took your response to suggest that you were addressing the Singleton Pattern, and not one specific instance of that.
Pete O'Hanlon wrote:
So, we're talking about introducing a method just to get through a test; not for any other purpose.
Yep.
