Blocking secondary thread
Hiren Shirishkumar Parikh -- hirenp@engin.umich.edu
Thursday, February 22, 1996
Environement : VC++ 4.0 / Win NT
I have an application where I need to block secondary thread(call it t2)
whenever other thread(call it t1) is blocked for I/O or any such operation.
Is it possible to raise an exception to block t2 whenever scheduler blocks
thread t1 for I/O or some network event.
Hiren
David W. Gillett -- DGILLETT@expertedge.com
Friday, February 23, 1996
[Mini-digest: 3 responses]
> Environement : VC++ 4.0 / Win NT
>
> I have an application where I need to block secondary thread(call
> it t2) whenever other thread(call it t1) is blocked for I/O or any
> such operation. Is it possible to raise an exception to block t2
> whenever scheduler blocks thread t1 for I/O or some network event.
Not without some cooperation from t2. [I'm kind of assuming here
that if there was a simple "suspend that thread" API, you would have
found it and wouldn't be asking the question.]
I think what you want is a semaphore, normally owned by t2. But at
fairly frequent (this becomes a tuning issue) intervals, t2 releases
and re-obtains the semaphore. t1, then, obtains the semaphore before
any such blocking I/O, and releases it afterwards.
t1 will usually have to wait for the semaphore, until t2 reaches a
point where it does a release and re-obtain. The re-obtain will
block t2 until t1 releases the semaphore.
This is a slightly stronger case than you've asked for, in that t2
will be suspended only at points chosen by the programmer.
[I'm not positive that a semaphore isn't overkill, unless you need
to go inter-process. The same concept can probably work with a
lighter-weight synchronization object such as a critical section or a
mutex.]
Dave
-----From: mikeblas@interserv.com
On Thu, 22 Feb 1996, Hiren Shirishkumar Parikh
wrote:
> Environement : VC++ 4.0 / Win NT
Thanks.
>I have an application where I need to block secondary thread(call it t2)
>whenever other thread(call it t1) is blocked for I/O or any such operation.
This is a pretty wierd requirement. It suggests that you shouldn't have two
threads... by task switching between two different threads like this, you're
wasting more time than you're saving. In other words, it suggests that your
design is lacking.
I guess I would do this by calling SuspendThread() before I/O and
ResumeThread() after the I/O.
>Is it possible to raise an exception to block t2 whenever scheduler blocks
>thread t1 for I/O or some network event.
No. Exceptions are thread-local.
.B ekiM
--
TCHAR szDisc[] = _T("Please be gentle: I have bad ankles.");
-----From: "Mark F. Fling"
Hiren Shirishkumar Parikh wrote:
>I have an application where I need to block secondary thread(call
>it t2) whenever other thread(call it t1) is blocked for I/O or any
>such operation. Is it possible to raise an exception to block t2
>whenever scheduler blocks thread t1 for I/O or some network event.
How about SuspendThread/ResumeThread on T2? Prevents re-dispatch of
T2 until resumed by T1.
Marty Fried -- mfried@linex.com
Sunday, February 25, 1996
>-----From: mikeblas@interserv.com
>
>On Thu, 22 Feb 1996, Hiren Shirishkumar Parikh
>wrote:
>> Environement : VC++ 4.0 / Win NT
>
>>I have an application where I need to block secondary thread(call it t2)
>>whenever other thread(call it t1) is blocked for I/O or any such operation.
>
>This is a pretty wierd requirement. It suggests that you shouldn't have two
>threads... by task switching between two different threads like this, you're
>wasting more time than you're saving. In other words, it suggests that your
>design is lacking.
>
I think I disagree somewhat about it being wierd. Sometimes the extra time
is insignificant, and it may be the quickest and simplest way to do something.
Sometimes the "do it now" requirement overrides a better engineered approach.
Neither approach should invalidate the other. If our compiler authors favor
a better engineered approach, I'm glad.
>I guess I would do this by calling SuspendThread() before I/O and
>ResumeThread() after the I/O.
>
But what happens if you suspend T2 in the middle of accessing the resource
that t2 needs? I think you need to use a mutex around the protected operations
so t1 can block until t2 releases the mutex. T2 would get the mutex whenever
it can't be interrupted, and release it when it's safe.
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Marty Fried (mfried@linex.com)
Marin County, California
Mike Blaszczak -- mikeblas@interserv.com
Tuesday, February 27, 1996
On Sun, 25 Feb 1996, Marty Fried wrote:
>>-----From: mikeblas@interserv.com
>>This is a pretty wierd requirement. It suggests that you shouldn't have two
>>threads... by task switching between two different threads like this,
>>you're wasting more time than you're saving. In other words, it suggests
>>that your design is lacking.
>I think I disagree somewhat about it being wierd. Sometimes the extra time
>is insignificant, and it may be the quickest and simplest way to do
>something.
Like what?
>If our compiler authors favor a better engineered approach, I'm glad.
Huh? I'm not sure what compilers have to do with this question.
>>>I guess I would do this by calling SuspendThread() before I/O and
>>>ResumeThread() after the I/O.
>>But what happens if you suspend T2 in the middle of accessing the resource
>>that t2 needs?
I'm not sure I follow you. If T1 suspends T2, and T2 is using a resource, it
doesn't matter. When T1 resumes T2, T2
>I think you need to use a mutex around the protected operations
>so t1 can block until t2 releases the mutex. T2 would get the mutex whenever
>it can't be interrupted, and release it when it's safe.
Do you mean that suspending _T2_ while it is in the middle of accessing a
resource that _T1_ needs _to do the I/O_? If that's true--it simply doing
SuspendThread() could cause a deadlock and you might need to consider using a
mutex, yes.
.B ekiM
--
TCHAR szFreeSoda[] = _T("Ask me how to get a job at Microsoft.");
Marty Fried -- mfried@linex.com
Thursday, February 29, 1996
At 01:10 PM 2/27/96 -0800, mikeblas@interserv.com wrote:
>On Sun, 25 Feb 1996, Marty Fried wrote:
>>I think I disagree somewhat about it being wierd. Sometimes the extra time
>>is insignificant, and it may be the quickest and simplest way to do
>>something.
>
>Like what?
I know whatever example I come up with will probably be full of holes, but
I'm open to other ideas, so here goes I wrote an app that controls a
digital disk recorder on a network using winsock. I used a thread that
updates a readout showing the current location, and checks the status to
update certain readouts. Any of these can change asynchronously, either
by program control or manual control, so I have to check regularly. The
simplest way was a thread that checks regularly.
But I also need to send commands like play, record, etc, which uses the
same socket, so I use synchronization around the winsock I/O.
>>If our compiler authors favor a better engineered approach, I'm glad.
>
>Huh? I'm not sure what compilers have to do with this question.
I'm just trying to say that some non-mission critical apps may not
be as well-engineered as more critical apps, such as compilers. I
picked compilers as an example thinking you are envolved with MSVC
somehow, and your approach is probably different than someone like me,
who is fighting the "get it out now, and fix it later" mentality.
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Marty Fried (mfried@linex.com)
Marin County, California
| Вернуться в корень Архива
|