Thread Processing

Henry Pham -- henry@csical.com
Wednesday, April 17, 1996


Hi,

Platform -   NT 3.51(Service Pk 3), 64 meg RAM,  VC++ 2.1

I have question on synchronizing threads in MFC.  I have a a static array of
thread handle pointer that I'm waiting on to be signaled in a thread.

I use WaitForMultipleObjects to put my current thread to sleep.  When one of 
the
thread handle  becomes signaled my thread will wake up. I prompt the user
that the paticular processes has been terminated and give the operator a
chance to restart the process. The operator may select to continue
without restarting this process.

What will happen if I set the process' handle in my static array of thread 
handles to INVALID_HANDLE or NULL and call WaitForMultipleObjects again?

What do I have to do to call  WaitForMultipleObjects again with a different
number of thread handles?

Thanks in advance for your help.

Henry@csical.com

---

Mike Blaszczak -- mikeblas@msn.com
Saturday, April 20, 1996

From: 	owner-mfc-l@netcom.com on behalf of Henry Pham
Sent: 	Wednesday, April 17, 1996 14:07 PM

> Platform -   NT 3.51(Service Pk 3), 64 meg RAM,  VC++ 2.1

Thanks.

> I have question on synchronizing threads in MFC.  I have a a static array of
> thread handle pointer that I'm waiting on to be signaled in a thread.

So, you have an array declared like this:

HANDLE *hMyArray[];

?  That's a little wierd.  Why haven't you simply declared

HANDLE hMyArray[];

?

> What will happen if I set the process' handle in my static array of thread 
> handles to INVALID_HANDLE or NULL and call WaitForMultipleObjects again?

Empircally, this seems to work... but I'm not using a checked build of Windows 
NT.  You should, I think, make the effort to write software that's correct and 
remove the NULL entry from the list.  Maybe NULL entries are okay, but nothing 
in the documentation says that, so I think you should avoid relying on that 
kind of behaviour. If you have this array declaration,

HANDLE hMyArray[];

and the number of elements in that array is nMyArraySize, you could remove an 
element by doing this:

void RemoveElement(int nIndexToRemove)
{
	ASSERT(nMyArraySize == 0);

	if (nIndexToRemove < nMyArraySize-1)
		memmove((void*) &hMyArray[nIndexToRemove],
			(void*) &hMyArray[nIndexToRemove-1],
			nMyArraySize - nIndexToRemove - 1);
	nMyArraySize--;
}

> What do I have to do to call  WaitForMultipleObjects again with a different
> number of thread handles?

What I said above: remove the entry you dont wan't, adjust the count, and call 
the API again.  If you really have an array of "thread handle pointers", as 
you said, I really don't know what you'd do because I'm not sure how you have 
that data structure set up.

.B ekiM
TCHAR szSpringtime[] = _T("Check twice and save a life: motorcycles are 
everywhere.");

---

David W. Gillett -- DGILLETT@expertedge.com
Tuesday, April 23, 1996

[Mini-digest: 3 responses]

> void RemoveElement(int nIndexToRemove)
> {
> 	ASSERT(nMyArraySize == 0);

  I believe this condition is backwards....

> 
> 	if (nIndexToRemove < nMyArraySize-1)
> 		memmove((void*) &hMyArray[nIndexToRemove],
> 			(void*) &hMyArray[nIndexToRemove-1],
> 			nMyArraySize - nIndexToRemove - 1);
> 	nMyArraySize--;
> }

  Unless I'm missing something crucial, WaitForMultipleObjects 
shouldn't care about the *order* of the handles, and so preserving 
the order here is unnecessary.  So I would write:

void RemoveElement( UINT nIndexToRemove )
{
    ASSERT( nIndexToRemove < nMyArraySize );
    ASSERT( nMyArraySize > 0 );  // redundant...

    if (nMyArraySize)  // do nothing if array is empty
        hMyArray[ nIndexToRemove ] = hMyArray[ --nMyArraySize ];
}

  [This moves the last element of the array to replace the element to 
be removed, and reduces the array size to drop the last element from 
its old position.]

Dave
-----From: "Mike Blaszczak" 

From: 	dgillett@expertedge.com on behalf of David W. Gillett
Sent: 	Tuesday, April 23, 1996 11:08

>  Unless I'm missing something crucial, WaitForMultipleObjects 
> shouldn't care about the *order* of the handles, and so preserving 
> the order here is unnecessary.  So I would write:

If you're not waiting for all objects to become signalled, the order does, 
indeed, matter.  If you were waiting for all objects to become signalled, you 
wouldn't care about removing items from the array one at a time.

.B ekiM
TCHAR sz[] = _T("TCHAR sz[] = _T(\"%s"\);");
-----From: "David W. Gillett" 

> >  Unless I'm missing something crucial, WaitForMultipleObjects 
> > shouldn't care about the *order* of the handles, and so preserving 
> > the order here is unnecessary.  So I would write:
> 
> If you're not waiting for all objects to become signalled, the
> order does, indeed, matter.  If you were waiting for all objects
> to become signalled, you wouldn't care about removing items from
> the array one at a time.

  You're right -- if you're not waiting for all objects, and two or 
more become signalled at once, the order will determine which one's 
index is returned.  So the order of the handles can be used as a 
priority mechanism, and an application might depend upon that.  [It 
didn't seem likely to me that an application that wants to remove 
items from the array one at a time was likely to care about the order 
in which signalled events are handled.  On further thought, though, I 
can imagine cases where it might be useful to specify and preserve 
this.]

Dave

---

| Вернуться в корень Архива |