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. ,Thread and Mutex

,Thread and Mutex

Scheduled Pinned Locked Moved C / C++ / MFC
question
4 Posts 3 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.
  • A Offline
    A Offline
    Anonymous
    wrote on last edited by
    #1

    Hi everyone, I have a thread. The function that keeps this thread alive contains a while loop. The while loop is true while a boolean variable is maintained true. When the thread has to terminate, the boolean value is modified to false and the thread dies. This boolean variable is global. I am using a Mutex to control access to this global value. I would like to know if it is necessary to control global variables with a Mutex when one is just reading the value? Or does one only control the global variable when one is going to modify its value? This one depends on the previous question. How does one manage something like: while ( g_bGlobal_Variable ) { } How does one apply a mutex object to the above case. Because I cannot do dwWait = ::WaitForSingleObject(); if ( dwWait == 0 ) { while ( g_bGlobal_Variable ) { } } Otherwise this implies that the thread always has control over the Mutex object while alive. Thanks and excuse the ignorance Regards

    S 1 Reply Last reply
    0
    • A Anonymous

      Hi everyone, I have a thread. The function that keeps this thread alive contains a while loop. The while loop is true while a boolean variable is maintained true. When the thread has to terminate, the boolean value is modified to false and the thread dies. This boolean variable is global. I am using a Mutex to control access to this global value. I would like to know if it is necessary to control global variables with a Mutex when one is just reading the value? Or does one only control the global variable when one is going to modify its value? This one depends on the previous question. How does one manage something like: while ( g_bGlobal_Variable ) { } How does one apply a mutex object to the above case. Because I cannot do dwWait = ::WaitForSingleObject(); if ( dwWait == 0 ) { while ( g_bGlobal_Variable ) { } } Otherwise this implies that the thread always has control over the Mutex object while alive. Thanks and excuse the ignorance Regards

      S Offline
      S Offline
      Scott H Settlemier
      wrote on last edited by
      #2

      First, if you're going to use a synhcronization object to protect a flag, use the synchronization object as the flag. i.e. Use an Event whose state is checked as a condition to exit the thread. (better yet use two events.. one to signal work to be done, the other to exit. wait (WaitForMultipleObjects) on both and then react appropriately.. that way your work thread won't waste cycles running through loops pointlessly.) Second, yes. Even access to resources should be protected (generally) since you want to ensure that the resource is not being modified while you are reading it. (or whatever) That said, some types of resources (small register-sized variables generally) can be read/written without the need of a protecting synchronization object. Check out the Interlocked_______ functions in win32.

      R 1 Reply Last reply
      0
      • S Scott H Settlemier

        First, if you're going to use a synhcronization object to protect a flag, use the synchronization object as the flag. i.e. Use an Event whose state is checked as a condition to exit the thread. (better yet use two events.. one to signal work to be done, the other to exit. wait (WaitForMultipleObjects) on both and then react appropriately.. that way your work thread won't waste cycles running through loops pointlessly.) Second, yes. Even access to resources should be protected (generally) since you want to ensure that the resource is not being modified while you are reading it. (or whatever) That said, some types of resources (small register-sized variables generally) can be read/written without the need of a protecting synchronization object. Check out the Interlocked_______ functions in win32.

        R Offline
        R Offline
        Ruca
        wrote on last edited by
        #3

        Thanks Scott I am sorry for the anonymous that was an error. Rui

        S 1 Reply Last reply
        0
        • R Ruca

          Thanks Scott I am sorry for the anonymous that was an error. Rui

          S Offline
          S Offline
          Scott H Settlemier
          wrote on last edited by
          #4

          Here's a code sample:

          // these handles are created and passed out to whoever'll
          // let the thread know when to work and when to quit

          HANDLE hWorkToBeDone=CreateEvent(0,FALSE,FALSE,0); // resets on wait
          HANDLE hTimeToQuit=CreateEvent(0,TRUE,FALSE,0); // once signalled, stays so

          // Basic thread loop

          HANDLE Waitables[]={hTimeToQuit,hWorkToBeDone};
          for (DWORD W=~WAIT_OBJECT_0;W!=WAIT_OBJECT_0;)
          {
          switch (W=WaitForMultipleObjects(2,Waitables,FALSE,INFINITE))
          {
          case WAIT_FAILED:
          // use GetLastError and handle this
          break;
          case WAIT_OBJECT_0: // It is time to quit
          break;
          case WAIT_OBJECT_0+1: // There is work to be done
          ; // Do some work
          break;
          case WAIT_TIMEOUT: // impossible? we specified no timeout
          default: // there should be no other cases. (e.g. for abandoned mutexes)
          ASSERT(FALSE);
          }
          }

          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