Re: How to allow a specific number of Instances of my app?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance


"WHoit" <WHoit@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:CA3CAE22-2271-49B3-8E2B-FE437782859A@xxxxxxxxxxxxxxxx


"Ralph" wrote:


"Ralph" <nt_consulting64@xxxxxxxxx> wrote in message
news:-LWdnZbsMed5-d7YnZ2dnUVZ_tWdnZ2d@xxxxxxxxxxxxxxx

"WHoit" <WHoit@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:9C71DF09-9269-4E0B-B0FB-0B523D2303BC@xxxxxxxxxxxxxxxx
I need to allow a specific number of instances of my app to run on a
pc.

For example, I may want to allow someone to run my app 3 times on
the
same
pc.

I don't want to use the "FindWindow" method because it's too weak
and
inaccurate.

I also don't want something that will "linger" if my app crashes,
thus
not
allowing future instances to run (i.e. no writing to files or the
registry).

It also has to be able to handle a user changing the name of the app
prior
to running it (checking running processes won't work in this case).

Does anyone have any suggestions?


Use Mutexs. Only instead of using it for a single instance, create a
"count" - if MutexOne, create MutexTwo, if Two ....



http://www.vbaccelerator.com/home/VB/Utilities/VBPZip/VBPZip_Source_Code_zip_mMain_bas.asp

-ralph


On further review, there is a problem with a Mutex if the App crashes.
As it
is the responsibility of an App to remove the Mutex to allow another
application to run.

Therefore, as much as it goes against the grain, you may need to invoke
another "clock". ie, create a file/Ini or Registry entry that indicates
when
an app starts and when it ends - rather normal for most fault-tolerant
applications. Depending on what your application does, you might even
need
to perform an inquiry, a la MS Word - "A previous instance was not
shutdown
properly, would you like to recover the previous file?" or even a brute
force approach - "The app has detected an error, please save and close
down
all apps." Perform your cleanup and restart. ... The list goes on.

Instrumenting an app to be fault-tolerant is a slightly different
ballgame.
<g>

-ralph

I was looking into a Mutex, but stopped for the exact reason you
mentioned -
the "crash" factor.

Isn't there some kind of unique indentifier for my app when it's running
(besides a process id or similar since they're based on names) that I can
look for?

Maybe I can set one (like a Mutex) in memory so that it disappears when
the
app stops, even by a crash?

I wouldn't mix the two strategies, ie, tracking instances, and
fault-tolerance. They seem related, but will end up with you using two
clocks to measure the same thing, which is always a bad idea. <g>

A mutex is good reliable solution for when everything goes ok. It is also
*usually* a good solution when things go bad as Mutexes are automatically
destroyed by the system when the app terminates, planned or unexpected.
(This kind of answers your last question.) So I would go with a Mutex to
manage instance-counts. And frankly I wouldn't worry that much about it for
the average users/desktop situation. Most users realize if something goes
wrong - a reboot in is their future. <g>

However, whenever an application experiences a "Bad Crash", all bets are are
off.

Fault-tolerance is almost always handled with a classic Watch Dog. Something
that can periodically check and see if everything is a it should be. How you
go about that, again depends entirely on what you need to watch for.
Different scenarios can be complex nightmares or a simple global key. The
question is, do you really need to go there?

Unique identities for your apps is also flexible. Use a shared
file/ini/registry entry. Use shared memory. Use DDE. Use messaging, pipes,
COM+, ... the world is yours. Which you might want or need depends entirely
on your problem domain (critical mission, file editor, server, pda, ...) and
your willingness to go there. <g>

hth
-ralph


.

Relevant Pages

  • Re: pthread_mutex is not released when process closes
    ... particular mutex, why would the next entity to aquire that mutex care about it? ... I have an app where two separate processes both access a single chunk of shared memory. ... If I were to include a CRC of the data in the shared memory area, then if one of them dies while holding the mutex, the other could easily verify whether the data is self-consistent simply by verifying the CRC. ...
    (comp.programming.threads)
  • Re: IOCP critical sections and mutexes
    ... then there is some bug in your ... routines but I recently started some preliminary stress test on a new server ... then pushes it in a queue that will be later processed by my main app ... If I use a mutex instead it works fine. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: IOCP critical sections and mutexes
    ... those are pulled from the queue via GetQueuedCompletionStatus ... BTW, for the record, both the user mode accessible mutex and critical ... My packets never go over 2k in size. ... then pushes it in a queue that will be later processed by my main app ...
    (microsoft.public.win32.programmer.kernel)
  • Re: IOCP critical sections and mutexes
    ... mismatch and invalid 'this' pointer). ... instance) and I get pretty much the same crash. ... I mush have done something stupid in my main thread app. ... If I use a mutex instead it works fine. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Mutex Problem
    ... the slave can) then yes, you can use CreateMutex in the master and OpenMutex ... Note, however, that if the slave app starts earlier, then it ... would not get the mutex. ... shared memory, and for this reason each of these applications tries to create ...
    (microsoft.public.platformsdk.security)