Sharing Data in Dll with other applications

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
techwiz120299Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

techwiz120299Author Commented:
URGENT !!
0
yodanCommented:
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?
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
techwiz120299Author Commented:
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
0
yodanCommented:
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.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
C++

From novice to tech pro — start learning today.