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
| Вернуться в корень Архива
|