Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Threading problem..

Threading problem..

Scheduled Pinned Locked Moved C / C++ / MFC
c++helplearning
3 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • L Offline
    L Offline
    Laing James
    wrote on last edited by
    #1

    I have a WIN32 application that creates and dispatches a number of threads that perform various tasks. Now, one of the threads in particular creates and dispatches another two threads; one which reads records into a list and one which writes the records from the list to an output. The threads are created by a call to AfxBeginThread(), specifying the name of the function that serves as the worker thread (not a member function), and the argument to the call is the 'this' pointer of the parent object creating the thread (Both workers need access to the member functions of their parent). When the number of lines to read and subsequentailly write, is small, ie) one or two. I get a really strange thread protection expception. 1. The parent dispatches the first thread; the reader. It starts right away. 2. The parent dispatches the second thread; the writer. It starts right away. 3. The parent thread then hits a WaitForMultipleObjects(), waiting for an event to be signalled by both child threads indicating that they are complete. 4. The wait is broken, the parent object goes through destruction and completes. 5. Protection exception. Thrdcore.cpp @ line 114 (in my listing). nResult = (*pThread->m_pfnThreadProc)(pThread->m_pThreadParams); I cannot for the life of me find out what the problem is. It is as if a thread is being dispatched again after the parent is complete, or there is some kind of thread-clean-up that expects the function pointed to by pThread->m_pfnThreadProc and its argument pThread->m_pThreadParams (which is the address of the parent object) to be still accessible. Which of course it cannot be as the parent object has already been destroyed. I have traced the process over and over and I cannot come up with a reason why this is happening. If anyone has any suggestions or pointers I would would very much appreciate them. James.

    G 1 Reply Last reply
    0
    • L Laing James

      I have a WIN32 application that creates and dispatches a number of threads that perform various tasks. Now, one of the threads in particular creates and dispatches another two threads; one which reads records into a list and one which writes the records from the list to an output. The threads are created by a call to AfxBeginThread(), specifying the name of the function that serves as the worker thread (not a member function), and the argument to the call is the 'this' pointer of the parent object creating the thread (Both workers need access to the member functions of their parent). When the number of lines to read and subsequentailly write, is small, ie) one or two. I get a really strange thread protection expception. 1. The parent dispatches the first thread; the reader. It starts right away. 2. The parent dispatches the second thread; the writer. It starts right away. 3. The parent thread then hits a WaitForMultipleObjects(), waiting for an event to be signalled by both child threads indicating that they are complete. 4. The wait is broken, the parent object goes through destruction and completes. 5. Protection exception. Thrdcore.cpp @ line 114 (in my listing). nResult = (*pThread->m_pfnThreadProc)(pThread->m_pThreadParams); I cannot for the life of me find out what the problem is. It is as if a thread is being dispatched again after the parent is complete, or there is some kind of thread-clean-up that expects the function pointed to by pThread->m_pfnThreadProc and its argument pThread->m_pThreadParams (which is the address of the parent object) to be still accessible. Which of course it cannot be as the parent object has already been destroyed. I have traced the process over and over and I cannot come up with a reason why this is happening. If anyone has any suggestions or pointers I would would very much appreciate them. James.

      G Offline
      G Offline
      Gary R Wheeler
      wrote on last edited by
      #2

      In step 3, you indicate that your parent thread waits for an object signalled by both threads that indicates that they are complete. The problem is, when each thread signals the event, they are still executing. Signaling the event causes the thread to pause its execution in favor of the thread waiting. If you delete the parent object at this point, and then the reader/writer threads continue, you will see the access violation. You need to wait for both threads to finish executing before deleting the parent object. You can do this using ::WaitForMultipleObjects, passing it an array containing the handles to the reader and writer threads.


      Software Zen: delete this;

      L 1 Reply Last reply
      0
      • G Gary R Wheeler

        In step 3, you indicate that your parent thread waits for an object signalled by both threads that indicates that they are complete. The problem is, when each thread signals the event, they are still executing. Signaling the event causes the thread to pause its execution in favor of the thread waiting. If you delete the parent object at this point, and then the reader/writer threads continue, you will see the access violation. You need to wait for both threads to finish executing before deleting the parent object. You can do this using ::WaitForMultipleObjects, passing it an array containing the handles to the reader and writer threads.


        Software Zen: delete this;

        L Offline
        L Offline
        Laing James
        wrote on last edited by
        #3

        Thanks for the update. That is spot on... The parent does wait with a WaitForMultipleObjects, but, I stupidly I coded the process to use CEvents instead of just using the HANDLE of each thread as the signal. Again. Many thanks.. James.

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • World
        • Users
        • Groups