of PostMessage in the broadcasting thread. and that seemed to have fixed
btw i have a vector of HWND's of each of the CWnds for each thread. I
iterate through the vector, sending a message to each window. The receiving
over via WM_COPYDATA to the process it's responsible for. the receiving
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
See below...
On Thu, 17 Jul 2008 13:47:36 -0700, "Nick Schultz" <nick.schultz@flir.com>
wrote:
I am having trouble with thread saftey..
I have a class A that has members
int m_count;
int m_data;
CCriticalSection m_ lock;
I have one thread that creates a single class A and sets m_count to the
number of threads it will be sending to.
as other threads are done with it, they then call the function A::remove()
which looks like:
void remove() {
m_lock.Lock()
****
There is no need to set a lock at all; use InterlockedDecrement.
****
if(!--m_count){
****
You don't need a lock at all. You can just write
if(InterlockedDecrement(&m_count) == 0)
*****
m_lock.Unlock();
****
The lock is a waste of time and effort. Lose it. For this purpose,
InterlockedDecrement
will work, and it is multiprocessor-safe.
****
delete this;
return;
}
m_lock.Unlock();
}
is this thread safe?
****
Yes, but unnecessarily complex. Note that you must set the m_count value
before releasing
the threads to do the work, and once set, it cannot be manipulated again
until all the
threads are completed. The reason is that even if you increment the
m_count value, it
might already have been decremented to 0 and consquently the object is
already deleted.
****
I would think so because it is accessing m_count only after it achieves
the
lock and can only enter the ifstatement when count == 0.
****
Your reasoning is correct but you have introduced a lock where none is
needed, because the
InterlockedDecrement already has this built-in
****
this does work for a minimal number of threads, about 10. however 10+,
the
program hangs, cpu usage goes to 100% (assuming its a spin lock) and after
a
while(~15 seconds) I get the error:
Unhandled exception at 0x7c91b1fa in canANALYZERBackend.exe: 0xC0000005:
Access violation writing location 0x0000001a.
and breaks at line 81 in afxmt.inl
****
And what is there? You did not mention which version of VS you are using.
In VS.NET
2003, this is the Lock() call, and it suggests that this is probably a
NULL pointer. So,
of course, the FIRST thing you would do is look at the call stack to see
how you got
there, you would look at 'this' to see if it is indeed NULL, and try to
figure out how you
ended up calling Lock() by using a NULL pointer. All of these actions
should be
reflexive.
The problem does not appear to be in your locking logic but in some part
of your program
unrelated to the locking logic. But backtrace information from the stack
would probably
be of great assistance in determining just how you managed to call
remove() on a NULL
pointer. Probably some timing error that only shows up when you use
larger numbers of
threads, meaning there is some other aspect of your code that is not
thread-safe. Key
here is that NOBODY should touch that pointer after the object has been
handed off to the
threads, and no thread should touch the pointer after the remove() call.
I expect you
might have something like this (which would be good coding practice)
whatever->remove();
whatever = NULL;
but the problem appears to be that after this sequence, you are still
managing to use the
'whatever' pointer.
joe
*****
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm