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. Other Discussions
  3. The Weird and The Wonderful
  4. Threads

Threads

Scheduled Pinned Locked Moved The Weird and The Wonderful
designhelplearning
5 Posts 4 Posters 31 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.
  • R Offline
    R Offline
    Rama Krishna Vavilala
    wrote on last edited by
    #1

    Programming wth threads is not easy as many newbies think. A few years back my company was downsized and I had to take ownership of some code written by another programmer. The first thing I had to fix was some resource leaks when a given task was canceled. The task itself happened on a worker thread. The UI thread had a cacel button to cancel the task. After examining the code, I found the following:

    void CTaskProgessDialog::OnCancel()
    {
    TerminateThread(m_pWorkThread->m_hHandle);
    }

    void CWorkerThread::DoTask()
    {
    AcquireResources();

    // code that does something

    ReleaseResources();
    }

    N E 2 Replies Last reply
    0
    • R Rama Krishna Vavilala

      Programming wth threads is not easy as many newbies think. A few years back my company was downsized and I had to take ownership of some code written by another programmer. The first thing I had to fix was some resource leaks when a given task was canceled. The task itself happened on a worker thread. The UI thread had a cacel button to cancel the task. After examining the code, I found the following:

      void CTaskProgessDialog::OnCancel()
      {
      TerminateThread(m_pWorkThread->m_hHandle);
      }

      void CWorkerThread::DoTask()
      {
      AcquireResources();

      // code that does something

      ReleaseResources();
      }

      N Offline
      N Offline
      Nemanja Trifunovic
      wrote on last edited by
      #2

      That's a "double horror" - using TerminateThread, and not using RAII for handling resources (admitedly, it wouldn't help in this case, since TerminateThread does not unwind the stack). I have learned some Erlang[^] recently, and it really made me re-think the way I write multithreaded code.


      Programming Blog utf8-cpp

      1 Reply Last reply
      0
      • R Rama Krishna Vavilala

        Programming wth threads is not easy as many newbies think. A few years back my company was downsized and I had to take ownership of some code written by another programmer. The first thing I had to fix was some resource leaks when a given task was canceled. The task itself happened on a worker thread. The UI thread had a cacel button to cancel the task. After examining the code, I found the following:

        void CTaskProgessDialog::OnCancel()
        {
        TerminateThread(m_pWorkThread->m_hHandle);
        }

        void CWorkerThread::DoTask()
        {
        AcquireResources();

        // code that does something

        ReleaseResources();
        }

        E Offline
        E Offline
        El Corazon
        wrote on last edited by
        #3

        As mentioned the termination of a thread should be internal, not with a Terminate command. Set a flag and wait for self-termination. You never know if a thread has a socket or file open, or any other resources. You can't simply say, no thread can ever aquire resources, and with multi-core and multi-processor allowing two simultaneous operations, it is even more difficult to judge if a terminate signal will work without memory leak even with back-to-back aquire()/release() because the terminate can occur in the middle of aquiring, before releasing, or in the middle of releasing. Terminates should all be handled gracefully from inside. The "code that does something" needs to check for a terminate early flag and release resources (if any) and go on. Simply putting aquire/release back to back will not save you. This is a common failure even with experts on threading thinking that back-to-back operations will not be interrupted. It's all a roll of the dice, back to back operations may make you think everything is okay because chances are reduced, but eventually it will show up as a problem, and then it will be difficult to repeat it for debugging. remember the core premise of threading: thou shalt not commit murder, all threads should be directed to suicide. ;)

        _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)

        R C 2 Replies Last reply
        0
        • E El Corazon

          As mentioned the termination of a thread should be internal, not with a Terminate command. Set a flag and wait for self-termination. You never know if a thread has a socket or file open, or any other resources. You can't simply say, no thread can ever aquire resources, and with multi-core and multi-processor allowing two simultaneous operations, it is even more difficult to judge if a terminate signal will work without memory leak even with back-to-back aquire()/release() because the terminate can occur in the middle of aquiring, before releasing, or in the middle of releasing. Terminates should all be handled gracefully from inside. The "code that does something" needs to check for a terminate early flag and release resources (if any) and go on. Simply putting aquire/release back to back will not save you. This is a common failure even with experts on threading thinking that back-to-back operations will not be interrupted. It's all a roll of the dice, back to back operations may make you think everything is okay because chances are reduced, but eventually it will show up as a problem, and then it will be difficult to repeat it for debugging. remember the core premise of threading: thou shalt not commit murder, all threads should be directed to suicide. ;)

          _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)

          R Offline
          R Offline
          Rama Krishna Vavilala
          wrote on last edited by
          #4

          Sure! I can't believe how many programmers (even experienced ones) don't know this.

          1 Reply Last reply
          0
          • E El Corazon

            As mentioned the termination of a thread should be internal, not with a Terminate command. Set a flag and wait for self-termination. You never know if a thread has a socket or file open, or any other resources. You can't simply say, no thread can ever aquire resources, and with multi-core and multi-processor allowing two simultaneous operations, it is even more difficult to judge if a terminate signal will work without memory leak even with back-to-back aquire()/release() because the terminate can occur in the middle of aquiring, before releasing, or in the middle of releasing. Terminates should all be handled gracefully from inside. The "code that does something" needs to check for a terminate early flag and release resources (if any) and go on. Simply putting aquire/release back to back will not save you. This is a common failure even with experts on threading thinking that back-to-back operations will not be interrupted. It's all a roll of the dice, back to back operations may make you think everything is okay because chances are reduced, but eventually it will show up as a problem, and then it will be difficult to repeat it for debugging. remember the core premise of threading: thou shalt not commit murder, all threads should be directed to suicide. ;)

            _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)

            C Offline
            C Offline
            codemunkeh
            wrote on last edited by
            #5

            "thou shalt not commit murder, all threads should be directed to suicide" :) Nice.


            Need Another Seven Acronyms...
            Confused? You will be...

            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