Problems with running multiple instances of an application?

Question

I have a client application (C++, Windows) that opens sockets, connects to a server, makes requests, receive responses and notifications. It does logging and saves preferences locally. What can be problems if I try to run multiple instances of this application which is prevented presently?

Answer 1

Sounds a little bit like a Web browser ;)

And like a typical Web browser, if your application is implemented correctly, you'll be able to run multiple instances fine.

Unfortunately, there are ways to botch the implementation, for example:

• Exclusively lock log or configuration files for prolonged periods, thus "stalling" other instances.
• Just plain ignore the concurrent access to files, leading to all sorts of possible corruptions.
• Act not just as a client but as a server as well, and listen to a hard-coded port (so the second instance will fail while attempting to open the same port).
• Incorrectly declare a mutex as "public" (and therefore shared between processes) instead of "private", leading to slow-downs and possibly deadlocks.
• There is a limit for number of GDI handles per session. If you application uses excessive handles, multiple instances taken together might reach that limit, even when each of them individually observes the 10000 handles-per-process limit.
• Be a CPU hog (e.g. through busy waiting). One CPU hog on a modern multicore CPU might pass unnoticed, but once the number of instances exceeds the number of CPU cores that's another story!
• Be a memory hog.
• Mismanage UI:
  • Use UI tricks such as "always on top" windows - multiple such windows on the screen at the same time is no fun!
  • Mismanage the taskbar notification area (e.g. display a tray icon for each instance). Will technically "work" but having excessive number of tray icons is not pleasant, especially if application does not also have a "regular" taskbar button.

Etc etc... Essentially whenever there is a shared resource (be it a filesystem, network, CPU, memory, screen or whatever), care must be taken when concurrently using it.

Answer 2

If your application is opening port for listening, only one instance could use that one particular port. If application is connecting to the remote host, OS will always pick the next available port so multiple instances can run in parallel in this case.

If all instances are sharing the same log and/or configuration file, parallel write might corrupt those files so writing operations should be protected by some synchronisation object (e.g. mutex).

Answer 3

By problems I presume you mean that multiple applications each do not create their own workspace for logging and preferences. Which would result in one instance overwriting and access data made by the other, resulting in undesired, and unpredictable results.

If you have access to the source code of the application I would suggest extending the application to create a folder with name that contains time stamped plus randon number to hold the session data - i.e. the logs and the preferences. This way, multiple instances can operate without interfering with one another.

However bear in mind that some preferences may be best made global - to save you having to set the preferences each time you load a new instance. It depends on your application and what it is doing as to what these global preferences may be.

If you don't have access to the source then the other option for multiple instances would be via virtualisation, multiples OSs on same machine each OS running one instance of the app.

Answer 4

Are you having a particular problem you are seeing? ie - is the application crashing when you execute a second instance?

From your description, you could fail to open the executable if the second application

• Tries to open the same socket the first opens
• Tries to open the same file the first opens

Outside of that, more detail is needed.