Re: IPC and Threading in DLL

From:

Ulrich Eckhardt <eckhardt@satorlaser.com>

Newsgroups:

microsoft.public.vc.language

Date:

Tue, 17 Apr 2007 17:48:51 +0200

Message-ID:

<3s6ff4-lse.ln1@satorlaser.homedns.org>

Ezmeralda wrote:

I have the following application requirements:

I need to have one DLL which may be used by several
processes at the same time. This DLL should communicate
to hardware and make the hardware available to all
the processes connected to the DLL.

I have the following design idea in mind:
- the first process connecting to the DLL starts a
  thread in DllMain() (DLL_PROCESS_ATTACH) which
  communicates to the hardware and puts data in
  a global shared section

Be careful, the things you can do in DllMain are limited. You could start a
thread on demand though.

- all other processes connecting to the DLL do
not start a thread but can access the data in
the global section

Feasible. You can use named objects that then work between processes.
Depending on the access style it might be easiest to simply use a named
event-object and allow only one process at a time to access the hardware.

- when the last proccess detaches from the DLL,
the communication-thread should be terminated

Now this is not possible, because threads are always associated with a
process.

Unfortunately, it seems that the communication thread
is already terminated when the process which created
this thread (i. e. the first process, that connected
to the DLL) is terminated. I require the communication
thread to keep running until the very last process detaches
from the DLL.

See above, threads are a process resource.

Do you have any solution to this problem?
Maybe the overall design idea is not good - do
you have better ideas to implement such things?

I'd go with either mutually exclusive access or a separate process. The
latter is in particular cleaner when it requires rather low-level hardware
access.