CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 6 of 6
  1. #1
    Join Date
    Aug 2010
    Posts
    47

    Question 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
    .

  2. #2
    Join Date
    Jul 2005
    Location
    Netherlands
    Posts
    2,042

    Re: Conflict in VC++ Pragma Area?

    Quote Originally Posted by wavering View Post
    (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?
    Cheers, D Drmmr

    Please put [code][/code] tags around your code to preserve indentation and make it more readable.

    As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky

  3. #3
    Join Date
    Aug 2010
    Posts
    47

    Re: Conflict in VC++ Pragma Area?

    Quote Originally Posted by D_Drmmr View Post
    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?"

  4. #4
    Join Date
    Jul 2002
    Posts
    2,543

    Re: Conflict in VC++ Pragma Area?

    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.

  5. #5
    Join Date
    Aug 2010
    Posts
    47

    Re: Conflict in VC++ Pragma Area?

    Quote Originally Posted by Alex F View Post
    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
    .

  6. #6
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: Conflict in VC++ Pragma Area?

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured