CEvent & WaitForSingleObject (auto-reset)

[Jimbo_Jimbob_Jiminator]

Haven't been here in a while. Haven't been doing any Windows programming for
some time.

I have an issue with CEvent & WaitForSingleObject. The likely issue is that
I have no idea what I'm doing but, if we put that aside and pretend that I
have a clue, it goes like this:

The default implementation for CEvent is auto-reset. That is how I want to
use it. I have only a main tread and a second thread so I do not have several
threads waiting.

I have looked in books and all over the web and all of the examples seem to
show how to start a thread or stop a thread with an event. In this case,
auto-reset is not that useful if you only have one worker thread anyway.

I am trying to control when a loop runs with the event. The issue is that
once the user clicks the button to allow the progress bar to be updated once,
it just keeps updating through completion. I figure that the state of the
CEvent should auto-reset and it should not run another iteration until the
user intiates it.

Regards,
Jim

Here are some code snips that show it:

//This is primarily from an example I found on the web. I added the
//WaitForSingleObject as a test case.
UINT TestThread(LPVOID lParam)
{
AfxMessageBox("Bite Me");

PTHREADINFOSTRUCT pTis = (PTHREADINFOSTRUCT)lParam;
pTis->pEvent->Lock();
for(int i=0;i<100;i++)
{
::WaitForSingleObject(pTis->pEvent, INFINITE) == WAIT_OBJECT_0;
//This sends a message to the main thread to update the status bar
PostMessage(pTis->hWnd,UWM_USER_THRD_UPPRG,i,100);
Sleep(100);
}
PostMessage(pTis->hWnd,UWM_USER_THRD_FIN,0,0);
delete pTis;
return 0;
}

void CPPage1::OnBnClickedButton1()
{
//Testing Wait Single Object. Sends message to main dlg that user clicked
//the button
LRESULT Rslt = ::SendMessage(m_pMainWnd->m_hWnd , UWM_TEST_WSO, 0, 0);
}

LRESULT CMainDlg::OnWSO(WPARAM wParam, LPARAM lParam)
{
//User clicked the button set event to allow progress bar another tick.
pTis->pEvent->SetEvent();
return 0;
}

[Alexander Grigoriev]

You can't use your CEvent pointer as an argument of WaitForSingleObject.
It's not an event handle.

And first of all, DON'T USE CEvent. Use ATL::CEvent, which is more sane.
MFC::CEvent is braindead.

"Jimbo_Jimbob_Jiminator" <JimboJimbo...@discussions.microsoft.com>
wrote in message news:17FE98C0-D85E-4BF4...@microsoft.com...

[Joseph M. Newcomer]

I wouldn't trust an MFC synchronization primitive as far as I could throw a 1960s
mainframe.

You are correct in your perception of what should happen. Have you considered trying it
with a simple Event object (HANDLE h = ::CreateEvent(NULL, FALSE, FALSE, NULL)?

I would consider a semaphore a better choice. Each click increments it, each iteration
decrements it.
joe

Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[Jimbo_Jimbob_Jiminator]

Thanks Alexander,

I see. I changed it to,

::WaitForSingleObject(pTis->pEvent->m_hObject, INFINITE) == WAIT_OBJECT_0;

and now it works as I expected.

I will look into the ATL stuff too though.

Regards,
Jim

[Jimbo_Jimbob_Jiminator]

Thanks Joe,

> I wouldn't trust an MFC synchronization primitive as far as I
> could throw a 1960s mainframe.

That's rich! ;-)
I'm going to assume that you're not a recent gym rat convert benching 350
lbs. Therefore, I should see the MFC sync thing as BAAAADDDDD.

I did get it working by using the handle as Alexander suggested. An
oversight on my part even after looking at it 100 times. I will look into
using ATL or Win32 instead.

It does amaze me though that a library that was a cornerstone in Windows
development can have so many flaws, in such an important concept, that
everyone with experience knows to avoid it.

Regards,
Jim

[Joseph M. Newcomer]

Of course, this is the natural consequence of failing to have looked at the return value!

I assumed that this was what you had originally written, because it would have made no
sense to use a CEvent pointer in a WFSO.

This is the natural consequence of failing to show your code. You get the wrong answer.
joe

[Joseph M. Newcomer]

It is very, very sad. As far as I can tell the synchronization classes in MFC had been
delegated to a summer intern who had once read about synchronization. Any system that
converts a WAIT_ABANDONED ("catastrophic failure") to a "wait completed successfully" is
so far beneath contempt that nothing can salvage it.
joe

[Faisal]

On Jul 2, 7:24 pm, "Alexander Grigoriev" <al...@earthlink.net> wrote:
> You can't use your CEvent pointer as an argument of WaitForSingleObject.
> It's not an event handle.
>
> And first of all, DON'T USE CEvent. Use ATL::CEvent, which is more sane.
> MFC::CEvent is braindead.

Does the ATL::CEvent and other synchronization classes have any
advantages compared to MFC's .
Our software is written completely based on MFC synchronization
classes. Is there any compelling reason to rewrite it using ATL sync
classes?

>
> "Jimbo_Jimbob_Jiminator" <JimboJimbobJimina...@discussions.microsoft.com>
> wrote in messagenews:17FE98C0-D85E-4BF4...@microsoft.com...

[Goran]

> Any system that
> converts a WAIT_ABANDONED ("catastrophic failure") to a "wait completed successfully" is
> so far beneath contempt that nothing can salvage it.

Nah, that's not __that__ bad. Provided doc isn't lying, WAIT_ABANDONED
is not catastrophic, it's quite specific: it's used for a mutex who
was "abandoned" (thread/process exited without ReleaseMutex). In that
case, it holds true that the guarded resource is free to be used -
entity that locked on it is decidedly not touching it anymore. (As
MSDN says, perhaps guarded resource is in an inconsistent state after
abandon - but that could well be the case even if mutex was properly
released).

Goran.

[Giovanni Dicanio]

Faisal ha scritto:

>> And first of all, DON'T USE CEvent. Use ATL::CEvent, which is more sane.
>> MFC::CEvent is braindead.
>
> Does the ATL::CEvent and other synchronization classes have any
> advantages compared to MFC's .

Reading this thread, and listening to senior experienced people like
Joe, it seems so.

> Our software is written completely based on MFC synchronization
> classes.

You can mix MFC and ATL code, at least since VC7.1 they made that
possible (probably it was harder in VC6).

Giovanni

[Giovanni Dicanio]

Giovanni Dicanio ha scritto:

> You can mix MFC and ATL code, at least since VC7.1 they made that
> possible (probably it was harder in VC6).

I mean: using MFC for GUI classes, and ATL for synch classes.

Giovanni

[Goran]

> Does the ATL::CEvent and other synchronization classes have any
> advantages compared to MFC's .

They are quite similar, certainly as far as basic functionality is
concerned. Look at CEvent of ATL and MFC:

Both have Set, Reset, Pulse. "Lock" operation is WFSO. MFC version
lacks OpenEvent wrapper - a downside (ATL has that). MFC version
prevents copying - an upside. ATL version has a relatively bad copy
constructor (handle is transferred from existing to a new instance -
not the best of ideas). ATL version allows "closed" state - a downside
(IMO). MFC version comes from CSyncObject that IMO poorly tries to
unite a CriticalSection and HANDLE-based objects - bad idea. E.g.
CSyncObject has a "name", but there's no name for CCriticalSection.
Or, it has Unlock(count, prevCount) - that is a WTF for all sync
object except CSemaphore.

I wouldn't worry, I know that MFC versions work. All is simple enough
to be verifiable at a glance and to find out about any gotchas.

Goran.

[Joseph M. Newcomer]

OK, I set the mutex. I start working on the shared state. Halfway through my
computations, the thread takes an access fault and terminates. The shared state is left
in some undefined and undeterminable state. It may be that the data is corrupted. Further
use of the data by other threads may result in further data corruption or other failures.
What part of "catastrophe" have I failed to define?

At the very least, the decision must be MINE to make, not made for me by some dweeb who is
totally clueless.
joe

[David Ching]

"Goran" <goran...@gmail.com> wrote in message
news:e6b10c49-48ed-44a1...@32g2000yqj.googlegroups.com...

>> Does the ATL::CEvent and other synchronization classes have any
>> advantages compared to MFC's .
>
> They are quite similar, certainly as far as basic functionality is
> concerned.

Yes, I had thought CEvent was like CString... originating in MFC and moved
to ATL so that it could be used by non-MFC apps. So when people talk about
the MFC CEvent, they are really talking about the (now) ATL CEvent.

-- David

[Alexander Grigoriev]

These are different designs, not plug-in replacement.

"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:4F1FFFE7-E418-42FD...@microsoft.com...