Conflict in VC++ Pragma Area?

I have a DLL which is written in Visual C++ 6.0. It is called from a program written in Visual Basic 6.0 (yes, I know, it is obsolete now but changing up will be a big task - maybe later!)

I may well have several copies running at the same time and in order for the copies to talk to each other (eg "I am copy 3 and you are copy 5") I use the Pragma area. This has been working pretty well but occasionally when running multiple copies one of them will crash, especially when the multiple copies are being generated (the program will say eg "you have a six core processor, do you want to run six copies?" and then generate five more copies of itself - it is looking for solutions to a big problem and may run for several days so six copies running will find a solution six times quicker generally speaking)

It crosses my mind that this could be because of conflict in reading and writing to from the Pragma Area. So, my question is:

"Is the Pragma Area automatically locked to prevent conflict or is this something I will have to do myself?"

All help and suggestions appreciated!
Bob
.

Quote:

---

Originally Posted by wavering

(the program will say eg "you have a six core processor, do you want to run six copies?" and then generate five more copies of itself - it is looking for solutions to a big problem and may run for several days so six copies running will find a solution six times quicker generally speaking)

---

Why not just create multiple threads?

Quote:

---

Originally Posted by D_Drmmr

Why not just create multiple threads?

---

Well, I guess that may have been a route (although it appears that VB6 is not really set up for multithreading). Anyway, I am far too far along the route to change now. My program is basically in its final form after a very long time in gestation so it comes back to solving my specific question viz

"Is the Pragma Area automatically locked to prevent conflict or is this something I will have to do myself?"

Do you mean #pragma data_seg - http://msdn.microsoft.com/en-us/libr...=vs.80%29.aspx ? This data is not synchronized automatically, you need to to this in your own code. You can use the named mutex for synchronization.

Quote:

---

Originally Posted by Alex F

Do you mean #pragma data_seg - http://msdn.microsoft.com/en-us/libr...=vs.80%29.aspx ? This data is not synchronized automatically, you need to to this in your own code. You can use the named mutex for synchronization.

---

Alex
Many thanks - that is what I feared!
Bob
.

And this is why multithreading would be better than trying to synchronise several instances of an application over the same data.
Accessing the data will be slower if it's across instances
named mutexes and semaphores are your only synchronisation available. These are considerably slower than (slow to fast) unnamed mutexes, events or critical sections. The difference is significant.

The OS itself will be having more overhead to keep X applications running vs the same amount of threads in a single application. Additionally you'll be forcing stuff out of the L1 and L2 caches faster by having multiple instances vs multithreads.

Sometimes multithreading isn't an option (especially in the case of old programs) however.



Ideally you want to solve your problem without having any form of shared data or synchronization needs. For some problems that's easy, for others that's hard or impossible.