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

Question RE. CriticalSection

Scheduled Pinned Locked Moved C / C++ / MFC
questionhelp
5 Posts 4 Posters 2 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.
  • B Offline
    B Offline
    Budric B
    wrote on last edited by
    #1

    Hi, I'm sharing an object between 2 threads and I need to synchronize it. The following is a model of my code: class SynchronizedObject { SynchronizedObject() //constructor { InitializeCriticalSection(&m_ThreadSynch); } CRITICAL_SECTION m_ThreadSynch; void Lock() { ::EnterCriticalSection(&m_ThreadSynch); } void Unlock() { ::LeaveCriticalSection(&m_ThreadSynch); } //now the functions with problem void A() { Lock(); B(); Unlock(); } void B() { Lock(); //do some stuff Unlock(); } }; For some reason when I call A() my code doesn't lock up. Am I using the Critical Section incorrectly? Or does it check which thread is trying to enter the critical section and allows the same thread to enter it multiple times (which I thought wasn't the case). What about Mutexes? Aside from synchronizing accross processes do they behave differently? What about Semaphores? Note: I've also tried to just put a member object CCriticalSection synch; and call synch.Lock()/Unlock() where appropriate. Same result.

    B A B B 4 Replies Last reply
    0
    • B Budric B

      Hi, I'm sharing an object between 2 threads and I need to synchronize it. The following is a model of my code: class SynchronizedObject { SynchronizedObject() //constructor { InitializeCriticalSection(&m_ThreadSynch); } CRITICAL_SECTION m_ThreadSynch; void Lock() { ::EnterCriticalSection(&m_ThreadSynch); } void Unlock() { ::LeaveCriticalSection(&m_ThreadSynch); } //now the functions with problem void A() { Lock(); B(); Unlock(); } void B() { Lock(); //do some stuff Unlock(); } }; For some reason when I call A() my code doesn't lock up. Am I using the Critical Section incorrectly? Or does it check which thread is trying to enter the critical section and allows the same thread to enter it multiple times (which I thought wasn't the case). What about Mutexes? Aside from synchronizing accross processes do they behave differently? What about Semaphores? Note: I've also tried to just put a member object CCriticalSection synch; and call synch.Lock()/Unlock() where appropriate. Same result.

      B Offline
      B Offline
      Blake Miller
      wrote on last edited by
      #2

      Critical sections block separate threads from entering the critical section, not the same thread. None of the synchronization objects, near as I ever read, will block the same thread from entering them. Mutexes behave differently because they can be 'abandoned'. If the process owning a mutex exits before releasing the mutex, another process waiting for it will be rleased with the result WAIT_ABANDONED. Semaphores are for controlling 'metered access' to an object. Now, in your instance, if Thread 2 called B(), then Thread1 would not be able to enter A() until Thread2 was done processing B(). Likewise, if Thread1 entered A() first, then thread2 could not enter A() or B() until Thread1 was done with A().

      1 Reply Last reply
      0
      • B Budric B

        Hi, I'm sharing an object between 2 threads and I need to synchronize it. The following is a model of my code: class SynchronizedObject { SynchronizedObject() //constructor { InitializeCriticalSection(&m_ThreadSynch); } CRITICAL_SECTION m_ThreadSynch; void Lock() { ::EnterCriticalSection(&m_ThreadSynch); } void Unlock() { ::LeaveCriticalSection(&m_ThreadSynch); } //now the functions with problem void A() { Lock(); B(); Unlock(); } void B() { Lock(); //do some stuff Unlock(); } }; For some reason when I call A() my code doesn't lock up. Am I using the Critical Section incorrectly? Or does it check which thread is trying to enter the critical section and allows the same thread to enter it multiple times (which I thought wasn't the case). What about Mutexes? Aside from synchronizing accross processes do they behave differently? What about Semaphores? Note: I've also tried to just put a member object CCriticalSection synch; and call synch.Lock()/Unlock() where appropriate. Same result.

        A Offline
        A Offline
        Axter
        wrote on last edited by
        #3

        Both CriticalSection and Mutex are recursive in Windows. Recursive mutex will not let the same thread block itself. You could try using the boost thread library, which does have non-recursive mutex. If you don't mind sticking with recursive logic, I recommend you use the smart pointers in the following link, which act as synchronized wrapper class for your object. http://code.axter.com/sync_ptr.h http://code.axter.com/sync_ctrl.h Top ten member of C++ Expert Exchange. http://www.experts-exchange.com/Cplusplus

        1 Reply Last reply
        0
        • B Budric B

          Hi, I'm sharing an object between 2 threads and I need to synchronize it. The following is a model of my code: class SynchronizedObject { SynchronizedObject() //constructor { InitializeCriticalSection(&m_ThreadSynch); } CRITICAL_SECTION m_ThreadSynch; void Lock() { ::EnterCriticalSection(&m_ThreadSynch); } void Unlock() { ::LeaveCriticalSection(&m_ThreadSynch); } //now the functions with problem void A() { Lock(); B(); Unlock(); } void B() { Lock(); //do some stuff Unlock(); } }; For some reason when I call A() my code doesn't lock up. Am I using the Critical Section incorrectly? Or does it check which thread is trying to enter the critical section and allows the same thread to enter it multiple times (which I thought wasn't the case). What about Mutexes? Aside from synchronizing accross processes do they behave differently? What about Semaphores? Note: I've also tried to just put a member object CCriticalSection synch; and call synch.Lock()/Unlock() where appropriate. Same result.

          B Offline
          B Offline
          Bob Stanneveld
          wrote on last edited by
          #4

          If you want your thread to lock up, use a semaphore object and the WairFor... functions. They don't allow a thread to enter the critical section twice when the state of the Semaphore is non-signaled. Behind every great black man...             ... is the police. - Conspiracy brother Blog[^]

          1 Reply Last reply
          0
          • B Budric B

            Hi, I'm sharing an object between 2 threads and I need to synchronize it. The following is a model of my code: class SynchronizedObject { SynchronizedObject() //constructor { InitializeCriticalSection(&m_ThreadSynch); } CRITICAL_SECTION m_ThreadSynch; void Lock() { ::EnterCriticalSection(&m_ThreadSynch); } void Unlock() { ::LeaveCriticalSection(&m_ThreadSynch); } //now the functions with problem void A() { Lock(); B(); Unlock(); } void B() { Lock(); //do some stuff Unlock(); } }; For some reason when I call A() my code doesn't lock up. Am I using the Critical Section incorrectly? Or does it check which thread is trying to enter the critical section and allows the same thread to enter it multiple times (which I thought wasn't the case). What about Mutexes? Aside from synchronizing accross processes do they behave differently? What about Semaphores? Note: I've also tried to just put a member object CCriticalSection synch; and call synch.Lock()/Unlock() where appropriate. Same result.

            B Offline
            B Offline
            Budric B
            wrote on last edited by
            #5

            Thanks for your replies. I didn't want the thread to lock up so this is perfect, but I wanted to confirm that that's how it worked and I'm not missing some small part of code.

            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