Re: Critical Section
On Nov 23, 10:02 pm, dushkin <talt...@gmail.com> wrote:
Hi All,
Suppose I have couple of class methods which N threads can access and
which deals with a common resource.
My need is that when one thread is inside one method, other threads
which wants to go to the second method will wait until the other
thread, in the first method, will release the common resource.
1. Is using a member CCriticalSection object and using it with
CSingleLock (lock, unlock) will do the job?
For example:
void CCCGWServerSimApp::InsertBusyThreadId(DWORD a_dwThreadId)
{
// Create object for Single Lock
CSingleLock lock(&m_csBusy);
// Lock
lock.Lock();
m_busySet.insert(a_dwThreadId);
lock.Unlock();
}
void CCCGWServerSimApp::RemoveFreeThreadId(DWORD a_dwThreadId)
{
//Create object for Single Lock
CSingleLock lock(&m_csBusy);
//Lock
lock.Lock();
m_busySet.erase(a_dwThreadId);
lock.Unlock();
}
A variant of this would do in your example. However, explicitly
calling Lock() and Unlock() is very, very wrong. You should never call
them like this. Instead, do this:
{
CSingleLock(&m_csBusy, TRUE); // TRUE = acquire the lock
m_busySet.erase(a_dwThreadId);
} // Lock automatically released here
Why is it so wrong to call Lock/Unlock? Well, Lock is not so bad, but
Unlock is catastrophic for exception-safety. Ask yourself this: are
you sure that there will be no exceptions between calls to Lock and
Unlock? And what will happen if there is? Answers are: no, you are
not. Even in simplest code like yours, there can be e.g.
CMemoryException (in InsertBusyThreadId). If there indeed is an
exception, your Unlock will not be called and your critical section
will stay locked, possibly forever.
C++ has RAII. Use it. In this case, it means
{ CSingleLock(&syncObject, TRUE); DoWork(); }
2. Is there a way to turn an object to a thread safe? For example MFC
\stl containers.
No, and you should not even try. They are not made for that and you
__will__ fail.
What you should do, if you want a thread-safe container, is to wrap it
through containment or protected/private inheritance, doesn't matter,
add a lock object and use it, probably in the way you've done above.
You probably also need to think through thread-safety of container
elements. E.g. you can't get a reference to an element out and release
a lock, because some other thread can come in and remove said element,
leaving you with destroyed object on your hands. Solutions to this are
to always get a copy of the element out, or put shared_ptr pointers to
data in the container (which amounts to "get a copy out", really), and
make pointed-to objects thread-safe, too.
Goran.