C / C++ / MFC

15-Jan-04 4:01

I wonder if anyone can advise me about the following.

I am currently working on an application that uses multiple worker threads to perform concurrent processing.
It requires 50+ workers (although it may require many more in the future), each instantiating an object to perform some processing.
I am using ::WaitForMultipleObjects() to wait for all the threads to terminate.
Now, some threads run very quickly as they do not have that much to do and so they tend to terminate even before the last worker thread has been dispatched.

As a result, the wait fails..
Do I assume correctly, that this occurs because the wait function determines that those threads that are already signalled and therefore have invalid handles are considered an error.

So, how do I contend with the fact that some threads may already be signalled before the wait gets called.
I would like to be able to wait until all the threads have completed before execeution of the main dispatching thread continues whether they are non-signalled or signalled before the wait is called.

Any comments or advice would be greatly appreciated.

James.

Mike Dimmick15-Jan-04 4:43

Mike Dimmick

15-Jan-04 4:43

The thread objects are not deleted until all handles are closed. As long as you're keeping your handles open until you need to Wait, you'll be fine. The system keeps the object around so that you can wait on the object, should you need to.

Be aware that a large number of threads will tend to cause context thrashing if they're contending for CPU time. Consider using a thread pool instead. See the QueueUserWorkItem function for using the built-in thread pool on Windows 2000 or later.

Anonymous15-Jan-04 4:54

Anonymous

15-Jan-04 4:54

Hi.

Thanks for the reply.
The issue is not one of too many threads competing for a timeslice, as 99% of them are only active for a fraction of their lifetime. Infact they are only active when told to be via event handling.

I have been looking through the archives and found an interesting discussion that I had not seen before concerning DuplicateHandle() or some such that I might be able to use to define a duplicate handle for each thread ensuring that the wait has valid handles to reference even if a child worker has already become signalled before the wait function is requested.

Cheers.
James

Diddy15-Jan-04 5:28

Diddy

15-Jan-04 5:28

How do you mean the wait "fails"? As in tells you that you've given it an invalid handle? The thread handle should still be valid until it's closed with CloseHandle, and should be deemed "signaled" if they have terminated - providing you tell WaitForMultipleObjects to wait for all objects pased (3rd parameter) it should wait for all the threads to terminate - I have a similar snippit of code that kicks off 64 threads off different life spans and that works.

Could you put up the code that starts and waits for the threads.

Also, are you starting the threads with CreateThread() or _beginthread(ex)?

Laing,James15-Jan-04 5:58

15-Jan-04 5:58

Hi.

I am using AfxBeginThread(), which as I now understand, invalidates the handle once the thread terminates.
So, I am going to look into DuplicateHandle() to try and circumvent the problem.

Thanks for your reply.

James.

Diddy15-Jan-04 6:04

Diddy

15-Jan-04 6:04

It does indeed - well MFC deletes the CWinThread has died. There is an easier way than DuplicateHandle - set m_bAutoDelete in you CWinThread after its been created - just make sure you create it in suspended state

Laing,James15-Jan-04 6:07

15-Jan-04 6:07

Hi.

Yeah, I have also just had a look at that.
Thanks for your reply.

Cheers.

Laing,James15-Jan-04 10:29

15-Jan-04 10:29

Hi.

Thanks for all the replies.
Problem fixed, although I think that I might have to redesign the threads dispatch process when I need to use more than 64 threads, the current max defined on my system.

Thanks to all your responses...

Abhishek Srivastava15-Jan-04 16:58

Abhishek Srivastava

15-Jan-04 16:58

you can set priority of ur thread so that they dont run so quickly using API SetThreadPriority()

Abhishek Srivastava
Software Engineer (VC++)
India ,Noida
Mobile no 9891492921 Smile | :)

MSDN installation

Rob Catterall15-Jan-04 3:15

Rob Catterall

15-Jan-04 3:15

Hi All,

I just installed January 2004 MSDN help. I can use it from the start menu fine but not from the F1 key in visual studio. Am I missing a registry entry or something?
Appologies if this is the wrong forum, please redirect if it is.

Cheers,

Rob

<this signature="" intentionally="" left="" blank="">

Maximilien15-Jan-04 3:25

Maximilien

15-Jan-04 3:25

IFAIK, newer versions of MSDN doesn't work with Visual Studio 6, only with 7.

Maximilien Lincourt
Your Head A Splode - Strong Bad

Gary Wheeler15-Jan-04 5:14

Gary Wheeler

15-Jan-04 5:14

At one point during the MSDN install, they display a dialog box asking if you wish to integrate the MSDN with Visual Studio. If you have both VS.NET 2002 and 2003 installed, they have the 2002 checkbox cleared and the 2003 checkbox set by default. You may want to reinstall the MSDN and see if that's the problem.

As someone else has mentioned, versions of the MSDN Library after the October 2001 edition no longer integrate with Visual C++ 6.0.

Software Zen: delete this;

Rob Catterall15-Jan-04 23:15

Rob Catterall

15-Jan-04 23:15

Hi Gary,

thanks for the reply, I hope you don't mind answering another question. Would you suggest that it is worthwhile upgrading from Visual Studio 6 (we have an MSDN subscription so I already have the software)? Can I continue to maintain VisualC++ 6 projects under vs.net, or can 6 and .net be installed on the same machine safely?

Cheers,

Rob

Gary Wheeler16-Jan-04 1:57

Gary Wheeler

16-Jan-04 1:57

Rob Catterall wrote:
Would you suggest that it is worthwhile upgrading from Visual Studio 6 (we have an MSDN subscription so I already have the software)?

Yes. While VS.NET has significant differences in the IDE from VC6, for the most part the changes are worthwhile. A number of editor functions that you used to have to write macros for are now provided directly. Speaking of which, if you use macros a lot, you're going to be really pissed off. Any macros you had from VC6 will have to be rewritten, since the IDE object model is completely different. Also, VS.NET 2002 had some bugs in the resource editors, which supposedly 2003 has corrected. We're at the tail end of a development cycle, so we haven't upgraded to 2003 yet, and I have no direct experience.

Rob Catterall wrote:
Can I continue to maintain VisualC++ 6 projects under vs.net

Sort of. VC6 projects will import directly into VS.NET and can be recompiled with little or no changes. The compiler may issue a few warnings about features that have been deprecated, but those are easily fixed usually. But. Projects that have been upgraded to VS.NET cannot be easily downgraded to VC6. There was a tool here on Code Project at one time to do just that. The other, more significant, concern is that projects compiled under VS.NET require the VS.NET versions of the C++ runtime and MFC DLL's to be loaded onto the target machine, and those DLL's aren't installed unless you put them there. The VC6 DLL's were included in the OS install.

Rob Catterall wrote:
can 6 and .net be installed on the same machine safely?

Yes. I recommend installing things in the following order: VC6, MSDN Library October 2001 (the last version that integrated with VC6), VS.NET, and the latest MSDN Library.

Software Zen: delete this;

OpenGL in an SDI app..!

Halloko15-Jan-04 2:30

Halloko

15-Jan-04 2:30

Hey all,

I'm currently making an editor for my latest game project. In order to make the application draw the OpenGL viewport each "frame" I'm currently using the OnTimer() message and then invalidating the view but I'm VERY interested in other ways to achieve this!

Do you guys have any experience doing this?

Thanks in advance,
Soren

567890123415-Jan-04 3:00

5678901234

15-Jan-04 3:00

You can use Multimedia Timer (see timeSetEvent) which has high precision. If you update the screen with high frequency, you may draw directly from timer message handler, without invalidating. OnDraw in this case should not be used.
Another way is using of idle time, you can see such applications here: http://nehe.gamedev.net/
However, this method doesn't look professional in Windows environment.

Alexander ^M.,15-Jan-04 5:32

Alexander ^M.,

15-Jan-04 5:32

better use a loop with Sleep calls at the end.

Don't try it, just do it! Wink | ;-)

Halloko15-Jan-04 5:49

Halloko

15-Jan-04 5:49

Alexander M. wrote:
better use a loop with Sleep calls at the end.

..in an MFC app? How's that?

Alex Farber wrote:
You can use Multimedia Timer (see timeSetEvent) which has high precision

Do I really need higher precision? I mean, I just need to constantly update the view.
Anyways, you're suggesting that I shouldn't use the OnDraw() message to do the drawing but rather my own function?

Any other suggestions?

LunaticFringe15-Jan-04 6:11

LunaticFringe

15-Jan-04 6:11

Use idle time processing. This is the technique you're looking for. If this is an MFC app, override OnIdle in the application class, and adapt the following handler code:

BOOL CAnApp::OnIdle(LONG lCount) <br />
{<br />
	  CWinApp::OnIdle(lCount);<br />
<br />
	  if (lCount >= 2)<br />
		    DoSomething();<br />
<br />
	  return(TRUE);<br />
}

Only do your processing when the lCount parameter is >= 2; the framework is doing it's thing when it's 0 and 1. If you return TRUE, the application will continue to call your OnIdle as long as the message queue is empty, and will re-commence calls to OnIdle after processing any messages that are received. Return FALSE and OnIdle will be called once (and only once) each time the message queue is emptied.

Halloko15-Jan-04 7:35

Halloko

15-Jan-04 7:35

First off, thanks for the great answer!

LunaticFringe wrote:
if (lCount >= 2)
DoSomething();

Would you recommend invalidating the view in order to update my OGL window or should I use a separate function? I mean, after all, I DO need the device context of the view which is automatically passed as a parameter to OnDraw().