Systemwide singleton or monostate. How?

[kwhitefoot]

Can anyone suggest a way to create a class that implements a systemwide singleton or monostate?

I need to write some code to serialize access to some hardware. I want to give access to several separate applications. This means that the hardware layer must be present the same state to all applications. The singleton pattern presented by Microsoft won't do because each application that uses the singleton actually gets it's own copy.

This was trivially easy in VB6 (Global Multiuse class in an ActiveX executable) but I have spent hours this weekend racking my brain and Googling for a solution in C# or VB.Net to no avail.

 

[JurkMonkey]

I would create your hardware controller as a kind of service. Have the app just sit there and all other apps can connect to it via sockets or remoting. Then create a class that any application can create an instance of that talks to the controller in the appropriate way.

This is actually a more controlled model than the typical ActiveX/COM Object Model.

 

[Flofy]

In .NET the application were divided in small islands called application domains. It means that if I want 2 applications to comunication I need to define a way for them to comunicate the information. There are several ways I can do that:

1. Web services, I can host an application in IIS and I can make others to the call my services, but based on the scenario you are telling I don't think this it the best way.
2. Enterprise Services( COM+ ), this is a very powerful way it also provides a Component Server tool that allows you to define through a UI if you want a singleton or not and how many objects it also handles transactions with 0 lines of code. But understanding Enterprise Services could be very changeling and complex depending or you needs. There are a lot of things involved.
3. .NET Remoting, is the best way I know to solve your problem, I think it is easy to learn, and it will suit your needs.

What you need to have in mind that is that you need a '
"server application" the application that will host your singleton(by the way it was not invented by Microsoft and yes it is the solution to your problem) and "client applications" that will use the singleton. If you need more information just let me know.

 

[chiph]

You can create a named Mutex object, which is shared amongst all applications on the machine because it is an object owned by the operating system.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[kwhitefoot]

Thanks everyone and sorry for not monitoring this. My laptop died (fan failure) so I've been catching up for the last several days.

I finally figured out that .NET remoting was what I needed to use. COM+ is out of the question because I want this to be simpler than the previous VB6 version not more complex.

It turns out that if I do that I don't need to use a mutex to prevent multiple instances because the remoting framework can enforce that for me. What I still miss from VB6/COM is the automatic startup of the server on demand. I think I'll have to create a simple class that checks to see if the server is alive and if not starts it. (I don't want to run services for this, I prefer everything to run in userland). Of course another way would be to have an equivalent of the inet daemon that would start the relevant server when a message came in on the relevant port; I have no idea how to do that so I'll stick with the easy way of attempting to interrogate the server when the client starts up and if that fails I'll start the server process. I'll use a mutex there to make sure that I only start one instance of the server registration code.

I didn't mean to imply that Microsoft invented the singleton pattern. What I meant was that the presentation of the implementation of a singleton class on MSDN was not adequate for my problem; the reason being that it was a singleton within a given process while I need a system wide singleton. Is it just me of is almost every description of singletons really very poor and riddled with assumptions about the application domain (usually that everything is in process and single threaded)?

 

[chiph]

the reason being that it was a singleton within a given process

Actually, it's unique within the AppDomain, not the Process. But since most people only use the default AppDomain, the distinction is usually not relevant.

Glad you got it working.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[Olegus]

Hi, I registered at tek-tips when I saw this question. I have exactly the same problem except there will not be direct remote connections to this system-wide singleton. Of course I can do remoting on the same machine, but it just does not sound right.
Also I'd like to host, instantiate, manage and kill this object in window app( or from window app). Is it possible with remoting?

 

[chiph]

If you're looking for a system-wide singleton, probably the best way would be to create a Windows Service, and then use Remoting to connect to it.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first