Re: IPC resource access counting problem

The problem here is that if program A is open and increments (and you MUST
use
InterlockedIncrement to increment the value, not ++!), program B opens and
increments, and
A crashes, then the file will not be deleted because A has not had a
chance to decrement.
It also only works if both instances are running on the same machine.

It doesn't surprise me that MS-DOS versions of pretend-Windows are full of
bugs. But it
helps if you are specific about which platform you are using, since most
of us treat these
kludges as dead products and ignore them.

One way I handled this was to have an array (fixed-size) of process IDs.
The array was
protected by a mutex. When a process starts up, it locks the table and
adds its process
ID to the array (for my purposes, I set the limit to 100, although we
never expected more
than 3 or 4 instances to run). When a process terminated, it did the
following:
Lock the table
               remove its process ID and decrement count
               if count== 0 take final cleanup action, we're done
if count > 0
for each element,
     check if the process exists
     SendMessageTimeout query
     if failure, remove element from table and decrement count
     if count == 0, take final cleanup action, we're done

The idea is that if a process of the same ID exists, there is a high
probability it is the
process that modified the program. However, because process IDs can be
recycled if a
prorcess terminates, I would call SendMessageTimeout to query the other
process with a
user-defined message. If I got a confirmation (the return value was the
user-defined
message ID...you can't use 0 or 1 because some processes written by MS
return 1 for
messages they don't understand...) then it was still my program; if I got
any other value
or a timeout (pick a short timeout like 50ms, I knew I'd never tie up the
message pump
that long...) I could decrement the count. We never had a problem again.
joe