Multi-threading and Accessing a Mutex

Hello everyone.

I just wanted to check if I was doing this correctly since I couldn't find anything on Google.

I'm creating a mutex and then checking and then taking ownership of it per thread and then releasing it.

But I'm not sure if I was taking ownership correctly.

Heres an example;

//Creation
bool good = false;
HANDLE goodMutex = CreateMutex(NULL,false,"goodMutex");

//Access per thread
WaitForSingleObject(goodMutex , INFINITE);
OpenMutex(SYNCHRONIZE,false, "goodMutex"); //<------ Not sure about this
good = true;
ReleaseMutex(goodMutex );


Can anyone tell me if I'm doing this right?

See what you can extract from the manual. Let us know if you have problems.
http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx
http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

gg

Quote:

---

Originally Posted by Codeplug

See what you can extract from the manual. Let us know if you have problems.
http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx
http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

gg

---

I had already taken a look at the CreateMutex page on MSDN, but the named objects one seems to make sense.

It would seem that I am accessing it correctly.

My issue was that Create and Close all work with handles, whereas Open doesn't.

If you are only synchronizing between threads in the same process, consider using a Critical Section.

If a cs won't work (because you need to use the WaitForXXX functions, then realize that you can pass the mutex handle to any thread that needs the mutex. In other words, there's no need to perform OpenMutex inside the thread.

Quote:

---

Originally Posted by Arjay

If you are only synchronizing between threads in the same process, consider using a Critical Section.

If a cs won't work (because you need to use the WaitForXXX functions, then realize that you can pass the mutex handle to any thread that needs the mutex. In other words, there's no need to perform OpenMutex inside the thread.

---

I'm spawning concurrent threads thats do the same task on different pieces of data with a shared source.

For example, I have a 3x3 grid that needs to be worked on.
I spawn a new thread for each of the nodes in that grid.
But, they share a common piece of data as well, in this case a deqeue that is in the class.

Thus, there needs to be opening of the mutex in the thread so that the cocurrent threads don't try to work on the data at the same time.

Quote:

---

Originally Posted by Shard

I'm spawning concurrent threads thats do the same task on different pieces of data with a shared source.

For example, I have a 3x3 grid that needs to be worked on.
I spawn a new thread for each of the nodes in that grid.
But, they share a common piece of data as well, in this case a deqeue that is in the class.

Thus, there needs to be opening of the mutex in the thread so that the cocurrent threads don't try to work on the data at the same time.

---

Understand that you may not need to use a mutex and can use critical sections. Like I mentioned, critical sections are ideal for in-process synchronization tasks (and they're faster than the kernel mode mutex).

You can use a critical section to control access to the dequeue. If each 'grid node' thread only ever operates on a single node (without any node overlap), then you may not need to synchronize thread access to each node.

Of course, you know what you need to do better than I.

Quote:

---

Originally Posted by Arjay

Understand that you may not need to use a mutex and can use critical sections. Like I mentioned, critical sections are ideal for in-process synchronization tasks (and they're faster than the kernel mode mutex).

You can use a critical section to control access to the dequeue. If each 'grid node' thread only ever operates on a single node (without any node overlap), then you may not need to synchronize thread access to each node.

Of course, you know what you need to do better than I.

---

So I took a look at the MSDN description of a critical section and it looked good except for:
"A critical section object cannot be moved or copied. The process must also not modify the object, but must treat it as logically opaque. "

My threads heavily modify the lists/objects that I'm currently using mutex's with.

Thoughts?

Quote:

---

Originally Posted by Shard

So I took a look at the MSDN description of a critical section and it looked good except for:
"A critical section object cannot be moved or copied. The process must also not modify the object, but must treat it as logically opaque. "

My threads heavily modify the lists/objects that I'm currently using mutex's with.

Thoughts?

---

Msdn is referring to the actual cs object, not the area of code it is protecting. The critical section will work fine.

Even better, use a RAII to thread synchronization. With RAII you write lightweight critical section and/or mutex wrapper classes and use another class which locks on acquisition and automatically unlocks on destruction.

Here's an example of a RAII implementation to remove items in a queue (of course, inserts and other queue operations would be guarded with the same technique).

Code:

---

void ClearItemQueue( )
{
  CAutoLockT< CItemQueue > lock( &m_ItemQueue );

  while( !m_ItemQueue.empty( ) )
  {
    delete m_ItemQueue.front( );
    m_ItemQueue.pop( );
  }
}

---

You can see a full sample in my reply in this thread: http://www.codeguru.com/forum/showthread.php?p=1688454