techwiz120299
asked on
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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
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
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.
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.
ASKER