Prev: Testing ....
From: Woody on 2 Jul 2010 17:42
I'm having difficulty devising a correct synchronization scheme for
the following.

There are four processes, each a dialog-based MFC app, written in C++,
built with VS2005. Call these processes Master, A, B and C.

The synchronization issues are these:

1) When any of the 4 processes is started, it must detect whether
another instance is already running. Normally this is done using a
global mutex, but that solution will not work unless the O/S
guarantees to run the app long enough to create the mutex. The
critical case is when two instances are started almost at the same
time.

2) When Master starts, it sets up some memory which is used by A, B
and C. The setup may take several msec. When any of A, B or C is
started, it needs to determine whether Master has (a) not been
started; (b) has been started, but has not finished its setup; or (c)
has finished its setup.

It is acceptable for A, B or C to wait for setup to complete if Master
is in state (b) above.

This is not actually an MFC problem, but a Windows O/S one, although
MFC may have some solution built in.

Any advice on how to solve these synchronization issues?
From: ScottMcP [MVP] on 2 Jul 2010 17:55
On Jul 2, 5:42 pm, Woody <ols6...(a)sbcglobal.net> wrote:
> I'm having difficulty devising a correct synchronization scheme for
> the following.
>
> There are four processes, each a dialog-based MFC app, written in C++,
> built with VS2005. Call these processes Master, A, B and C.
>
> The synchronization issues are these:
>
> 1) When any of the 4 processes is started, it must detect whether
> another instance is already running. Normally this is done using a
> global mutex, but that solution will not work unless the O/S
> guarantees to run the app long enough to create the mutex. The
> critical case is when two instances are started almost at the same
> time.

That's not really a problem. Whichever process calls CreateMutex
first is the first process. Another process started at almost the same
time will find that the mutex already exists.


>
> 2) When Master starts, it sets up some memory which is used by A, B
> and C. The setup may take several msec. When any of A, B or C is
> started, it needs to determine whether Master has (a) not been
> started; (b) has been started, but has not finished its setup; or (c)
> has finished its setup.

This issues disappears if, instead of using a global mutex, you use a
global named shared memory. Whichever process calls CreateFileMapping
first is the first process. Another process started at almost the
same time will find that the mapping already exits.
 | 
Pages: 1
Prev: Testing ....