Sharing Data in Dll with other applications

Posted on 1999-12-09
Medium Priority
Last Modified: 2010-04-01
How do I share data in my Dll with 3 other applications(EXE). Data to be shared is Message Queues which have been implemented using Deques
Question by:techwiz120299
  • 2
  • 2

Author Comment

ID: 2270927

Accepted Solution

yodan earned 450 total points
ID: 2271011
If you use deques of STL (in MSVC++ named Standard C++ Classes), and want to return or receive (as arguments) of type deque, you are in for some work.
Most of the  STL's use static data and that creates symbols local to every linked binary (DLL or EXE for instance) defined.
This means you will have addresses in one DLLA that are incompatible with another EXEB, since in EXEB the address has different meaning.
One of the Microsoft sugestions is to export all types of STL used in one DLL and then import on the other DLL (clients...).
That implies you will export more than deques since one STL class is usually close-coupled with some other STL classes.
Like it?
One possibility is to use a proxy class - meaning the same as an interface class - wich 'negotiates' deque reading, writing, manipulation. That way you don't use deques directly.
In the same sense you think of it, or use the Message Queue as an ADT (Abstract Data Type), without exposing - directly - any method of deque. You can convert in and convert out, too.

If the Deques are from MFC or other similar MS defined types, possibly you can export/import data directly.

As you may know DLL's have static member data, and from the moment you load it until explicitly unloading it will keep it.
So you just declare an instance as global/file scope and then take care for multitasking and concurrence and first time initialization. The data is imediatly shared but you wouldn't want  to do that directly. Use a class that manages clients: each instance is a "connection" and inside that class methods you may use Mutexes...

For a more specific help, more up to the tasks comments, post more details:
Wich kind of DLL you intend? MFC, C++, C-interface(but using C++), ...
What type of deques you use? What do you mean with sharing data?
What is(are) your true problems implementing the code?

Author Comment

ID: 2271284
DLL intended is of type C++. I don't want to use MFC as can't afford to make system heavy. CPU utilization should be below 15%.

Iam using Deques for esatblishing a messaging queue between 3processes using this messaging queue DLL.

Suppose I start Proc.A which in turn starts Proc.B and ProcB starts ProcessC.
Now, process B adds a message to the messsage queue which is for ProcessA.
How should  ProcessA read the message intended for it ??
Same for vice-versa and for Proc.B&C nad for Process A&C !!

One more thing ::
My process B in turn creates say 100 threads, so how should i make sure that each thread is adding its own message to the message queue.
What is happening right now is that only either the first or the last thread is adding messages to the queue. Rest all which are in between are not able to add messages to the queue??

Please explain in detail how to solve this problem

Expert Comment

ID: 2271784
Oops, seems you have a lot more complexity than I was thinking.
One advise: If you have more than one processor in the machine  you can ran each thread (in NT of course, Win95 doesn't provide SMP) on one processor, but you should - perhaps - reduce thread # creation, for then you may have a lot of trashing. Threads are naturally less expensive than process, but still expensive. If look in perfmon for the amount of threads in the systems you'll see how many you have... For OS...

About processes:
 you can share DLL code between processes, and static data between them all. You should use a common interface shared by clients and a message _server_ object in the DLL.
If you make your processes run the processor% will grow until it reaches the available resources (100%) unless you use some way of giving away the processor - Sleep(<time>).
I really advise you to use a message-server with say Send() mehtods and Receive() with the apropriate args(destiny?, message?,receiver <= "I'm process X"). This will work like sockets (almost).
The server may, also, actively dispatch messages and the clients will be waiting consumers.

About threads:
Let's have it like this: Do you really need to have that much threads? Can't you have instead one 'master' thread for one pool of jobs and dispatch the processing for one 'item'/method at each time?

About sharing and execution:
You should guard the Common-deque against concurrency by using a mutex for each end of the deque... Encapsulate it in the 'Server' class.
From what you're saying it seems that you have one process blocking the others...
How do you check for new messages ?
I've used a new 'kind' of semaphor for a similar problem, one that locks in both bounds - upper and lower - (of course you guessed right: two resource-count semaphores work as one sem, one makes --, other ++ and vice-versa). That 'stores' the message count.
I used a mutex for variable changes...

The message reader (or consumer) will be waiting for the queue to have messages, and so you avoid polling.
In your case, if you have destiny-oriented messages (from XPTO to proc.A-only for instance) you should use 3 semcounts, one for each process: proc.A, proc.B, proc.C. That simply means  - possibly - 3 deques also.

You may have a live-run(starvation) where the other processes/threads never get selected by the OS-dispatcher because one/two of the threads is(are) monopolizing the resources, the remaining will 'starve' for work.

One other notice: beware that Mutexes can be unlocked by thread owner _ONLY_. You can't create one mutex in one thread and hope that other handler-knowing thread releases it.
You may/should use a 1-unit-count semaphor instead.

This is complex, today I have to finish some code, but tomorrow I may have some more answers for you, but hoped I helped further. Do you still have ideas to try?

For debugging, try to use breaks in the thread code and check the other threads stack, to see if they're really locked. Use the MSVC++ menu  "Debug| Threads" for that.
send me mail for monteiro.bruno@netc.pt, I will read it this evening, tomorrow morning, for monday.

You said it's urgent but this ain't no easy problem for say one afternoon.

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Templates For Beginners Or How To Encourage The Compiler To Work For You Introduction This tutorial is targeted at the reader who is, perhaps, familiar with the basics of C++ but would prefer a little slower introduction to the more ad…
Go is an acronym of golang, is a programming language developed Google in 2007. Go is a new language that is mostly in the C family, with significant input from Pascal/Modula/Oberon family. Hence Go arisen as low-level language with fast compilation…
The viewer will learn how to pass data into a function in C++. This is one step further in using functions. Instead of only printing text onto the console, the function will be able to perform calculations with argumentents given by the user.
The viewer will be introduced to the member functions push_back and pop_back of the vector class. The video will teach the difference between the two as well as how to use each one along with its functionality.

624 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question