"Not Responding" message was coming from. To be fair, I see this a lot in
Vista (way more than XP) especially when using Visual Studio. There are
into play. I'm not sure what triggers it. Thanks for your explanation of
the message queue limit. That supports the conclusions we came to that
"Joseph M. Newcomer" <newco...@flounder.com> wrote in messagenews:agefu391ij7oc61dj7ehamatc4206g8onf@4ax.com...
I have scrolled through the thread I have downloaded, and this is your only
post...
Not to say that some other NG server might have them, but mine didn't.
joe
On Mon, 24 Mar 2008 06:31:44 GMT, Dan Bloomquist <publi...@lakeweb.com>
wrote:
Joseph M. Newcomer wrote:
It's a nasty one. Shocked me the first time I hit it...
joe
On Sun, 23 Mar 2008 21:23:54 +0100, "Giovanni Dicanio"
<giovanni.dica...@invalid.com>
wrote:
"Joseph M. Newcomer" <newco...@flounder.com> ha scritto nel messaggio
news:fqadu3poeb3hq6qrct5c82galu2crmumco@4ax.com...
See my earlier note on PostMessage queue saturation and you can see my
essay on the use of
I/O Completion Ports to avoid this problem.
Thanks Joe.
I was unaware of PostMessage queue saturation problem.
I'm curious. I posted an example of this a few days ago. Are my posts
not coming through?
Post:
***
I put a thread in a sample dialog to see if I could break it.
Thread object:
struct TS
{
CString strT;
CDialog* pDlg;
bool bTReady;
};
class CA_Dialog_AppDlg : public CDialog
{
TS ts;
...
};
I'm sharing a CString that is on the dialog stack. It should have been
on the heap.
UINT Thread( LPVOID pParam )
{
TS& strct= *static_cast<TS*>( pParam );
for( long i= 0; ; ++i )
{
//if( strct.bTReady )
{
strct.strT.Format( _T("Test This %d"), i );
::PostMessage( *strct.pDlg, ID_CHECK_THREAD, 0, 0 );
****
This is truly weird, because you are using a shared variable and bizarre
simulated
locking, and there is no need to do ANY of this, because you can pass a
pointer in the
message itself! This means that you aren't going to lose anything, and
you don't need to
do ugly polling loops!
I wouldn't trust this code to work correctly in a multiprocessor.
Also, why not just write
strct.pDlg->PostMessage(ID_CHECK_THREAD);
which is much simpler?
****
strct.bTReady= false;
}
//Sleep( 5 );
//for( long j= 0; j < 20000; ++j )
;
}
return false;
}
In init dialog:
ts.pDlg= this;
ts.bTReady= true;
pThread= AfxBeginThread( Thread, &ts, THREAD_PRIORITY_LOWEST, 0,
CREATE_SUSPENDED );
pThread->m_bAutoDelete= FALSE;
pThread->ResumeThread( );
and member:
LRESULT CA_Dialog_AppDlg::OnCheckThread( WPARAM, LPARAM )
{
SetWindowText( ts.strT );
ts.bTReady= true;
return false;
}
With the 'if( strct.bTReady )' in the thread commented the dialog is
swamped with messages and is dead. But it would not crash and the title
bar updates! I figured that I would catch CString with an invalid
pointer and I may have if I'd kept going. But that is the point,
bTReady is used to make sure the thread is not changing data while the
app is using it. It also makes sure the thread doesn't post more
messages than the app can handle.
****
None of this makes sense, because in a multithreaded environment, you
should not be
sharing a variable without using an interlock. I don't see any mutex or
CRITICAL_SECTION
here, and that will be fatal. This is really marginal code, especially in
a
multiprocessor. Without the strc.bTReady test, there is no way that this
can be safe. You
are creating a fragile and probably incorrect solution to the problem. If
you really want
to "throttle" the sending thread, you should be using a semaphore with a
max count of 1,
and just put a butter pointer in the message, rather than using these
bizarre interlocks.
sending thread:
WaitForSingleObject(strct.semaphore, INFINITE);
strct.pDlg->PostMessage(ID_DATA, buffer);
handler:
CString * s = (CString *)wParam;
...use string
delete s;
ReleaseSemaphore(semaphore, 1, NULL);
That's what semaphores are for. The code you show cannot be trusted to be
correct in all
situations, and by using polling, you are wasting significant amounts of
energy.
****
I also didn't stop the thread when the app quit, I just deleted it. But
to do it right it takes another semaphore that absolutely tells the
thread to exit. That means in every:
****
I don't see a semaphore, I see a boolean variable. But yes, you should be
using the
boolean variable. See also my essay on worker threads, because if you are
blocked on the
WFSO you can use WFMO with a shutdown event to break loose.
Polling hacks are just hacks.
****
while( ! strct.bTReady && ! strct.bKill )
::Sleep( 5 );
****
Anything between Sleep(1) and Sleep(15) is the same as Sleep(15). Note
that sleep times
are always rounded up to the next clock tick interval. This is actually
exceptionally
poor multithreaded style. You should not be polling. Polling is just a
hack, and not
usually a safe one, either.
joe
****
In the exit:
ts.bKill= true;
WaitForSingleObject( pThread->m_hThread, INFINITE );
delete pThread;
Best, Dan.
***
And, Best, Dan.
Joseph M. Newcomer [MVP]
email: newco...@flounder.com
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm