Waiting on a Thread - Revisited

[Charles Law]

Hi guys. I'm back on the threading gig again.

It's the age-old question about waiting for something to happen without
wasting time doing it.

Take two threads: the main thread and a worker thread. The worker thread is
reading the serial port, waiting for something to happen (a service
request). When it does it raises an event. Of course, the event is executed
on the worker thread. The idea is that when the event is raised, the handler
issues a command on the serial port and waits for a response. The problem is
that the part of the worker thread that does the listening (for replies) is
tied up with the event it has just raised, and therefore cannot listen for
the latest reply.

So, I think that when the event is raised, I need to set a flag perhaps,
that can be picked up on the main thread. This way the event completes, the
worker thread goes back to listening for replies, and the main thread sees
the flag and issues its command.

Sounds good, but now I have to periodically check for the flag in the main
thread. That sounds an awful lot like polling to me, and I don't want to
waste time polling.

How can I catch the flag in the main thread when it changes, without having
to sit and wait for it?

As usual, any suggestions about how else to do this are always welcome,
however radical.

TIA

Charles

[Cor Ligthert]

Re: Waiting on a Thread - Revisited

Hi Charles,

When I see your problem my answer is direct remoting, however maybe this can
also done by a threading program. It is a problem old as hell. There is in
my opinion needed a stack.

So why not create a stack using an arraylist.

You start your sub tread every time something is done from the first row of
that arraylist (when the tread is not active you can polling the arraylist
using the thread.threadin g.sleep if there is something) and delete that
item it is done.

While you add every time to the last row when there is something to be done,
this simple solution would work in my opinion

Cor

[Jon Skeet [C# MVP]]

Re: Waiting on a Thread - Revisited

Charles Law <blank@nowhere. com> wrote:

<snip>
[color=blue]
> Sounds good, but now I have to periodically check for the flag in the main
> thread. That sounds an awful lot like polling to me, and I don't want to
> waste time polling.
>
> How can I catch the flag in the main thread when it changes, without having
> to sit and wait for it?
>
> As usual, any suggestions about how else to do this are always welcome,
> however radical.[/color]

I'm afraid I didn't follow your example very closely, but it sounds
like you basically want Monitor.Wait and Monitor.Pulse.

I've got an unfinished article which talks about them (and other
things) - it's at

http://www.pobox.com/~skeet/csharp/multithreading.html

There's more to come when I get round to it, but the bit in "More
Monitor methods" described Wait and Pulse.

(You could also use ManualResetEven t or AutoResetEvent. )

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Charles Law]

Re: Waiting on a Thread - Revisited

Hi Cor

I have just read Jon's article on multi-threading in .NET and I now
understand how the Wait and Pulse methods work, so I am going to try that.
It looks like just the job.

Thanks for your suggestion though, as I think it is going to help me in
another area, related to the same task.

Charles


"Cor Ligthert" <notfirstname@p lanet.nl> wrote in message
news:OZp%230SkQ EHA.2452@TK2MSF TNGP11.phx.gbl. ..[color=blue]
> Hi Charles,
>
> When I see your problem my answer is direct remoting, however maybe this[/color]
can[color=blue]
> also done by a threading program. It is a problem old as hell. There is in
> my opinion needed a stack.
>
> So why not create a stack using an arraylist.
>
> You start your sub tread every time something is done from the first row[/color]
of[color=blue]
> that arraylist (when the tread is not active you can polling the arraylist
> using the thread.threadin g.sleep if there is something) and delete that
> item it is done.
>
> While you add every time to the last row when there is something to be[/color]
done,[color=blue]
> this simple solution would work in my opinion
>
> Cor
>
>[/color]

[Charles Law]

Re: Waiting on a Thread - Revisited

Hi Jon

I have just read your article and the mud has cleared (a little). I have
created another thread to respond to service requests, so as not to hold up
my main thread, and used the Wait and Pulse methods to signal between the
worker thread and the new thread. Just a few refinements to make and it'll
be there ... ;-)

Cheers.

Charles


"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1b1d34 94c79a7dd298a9e b@msnews.micros oft.com...[color=blue]
> Charles Law <blank@nowhere. com> wrote:
>
> <snip>
>[color=green]
> > Sounds good, but now I have to periodically check for the flag in the[/color][/color]
main[color=blue][color=green]
> > thread. That sounds an awful lot like polling to me, and I don't want to
> > waste time polling.
> >
> > How can I catch the flag in the main thread when it changes, without[/color][/color]
having[color=blue][color=green]
> > to sit and wait for it?
> >
> > As usual, any suggestions about how else to do this are always welcome,
> > however radical.[/color]
>
> I'm afraid I didn't follow your example very closely, but it sounds
> like you basically want Monitor.Wait and Monitor.Pulse.
>
> I've got an unfinished article which talks about them (and other
> things) - it's at
> http://www.pobox.com/~skeet/csharp/multithreading.html
>
> There's more to come when I get round to it, but the bit in "More
> Monitor methods" described Wait and Pulse.
>
> (You could also use ManualResetEven t or AutoResetEvent. )
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

[Charles Law]

Re: Waiting on a Thread - Revisited

Hi Jon

I have implemented a solution using SyncLock, Wait and Pulse, and all is
well. My CPU time has gone down from 30% to nil, which always cheers me up
:-)

However, I am noticing some odd behaviour. My previous solution used a do
loop, with DoEvents in it and a test for my flag, whereas the current
solution calls

Monitor.Wait(my flag, 100)

to wait for 100ms before returning.

Using DoEvents, I could click on a checkbox on-screen and it would change
state with each click. Now, using Monitor.Wait, I have to click the box
several time before it changes state. It's as if the UI is not getting time
to service the clicks.

Is that behaviour you would expect using Monitor.Wait?

At this point I have three threads running: the main UI thread, a comms
thread that listens to the serial port, and a thread that waits for service
requests from the comms thread. The comms thread call Monitor.Pulse(m yflag)
whilst the service request thread call Monitor.Wait. On that basis, I would
expect the UI thread to be unhindered, but that does not seem to be the
case.

Charles


"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1b1d34 94c79a7dd298a9e b@msnews.micros oft.com...[color=blue]
> Charles Law <blank@nowhere. com> wrote:
>
> <snip>
>[color=green]
> > Sounds good, but now I have to periodically check for the flag in the[/color][/color]
main[color=blue][color=green]
> > thread. That sounds an awful lot like polling to me, and I don't want to
> > waste time polling.
> >
> > How can I catch the flag in the main thread when it changes, without[/color][/color]
having[color=blue][color=green]
> > to sit and wait for it?
> >
> > As usual, any suggestions about how else to do this are always welcome,
> > however radical.[/color]
>
> I'm afraid I didn't follow your example very closely, but it sounds
> like you basically want Monitor.Wait and Monitor.Pulse.
>
> I've got an unfinished article which talks about them (and other
> things) - it's at
> http://www.pobox.com/~skeet/csharp/multithreading.html
>
> There's more to come when I get round to it, but the bit in "More
> Monitor methods" described Wait and Pulse.
>
> (You could also use ManualResetEven t or AutoResetEvent. )
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

[AlexS]

Re: Waiting on a Thread - Revisited

Hi, Charles

if you use Wait on UI thread - that's the reason. Wait passes effectively
control out of calling thread, so it's even worse than DoEvents in this
respect. If you use lock on UI thread on same object(s), which are used in
Monitor.Wait - that's one additional reason.

I lost track of original questions/answers, so can recommend only - remove
Wait from UI thread and check what and where you lock. Attach event to
thread object, assign UI thread delegate to event when constructing thread
and use Pulse in UI thread and Wait in worker thread. Minimize time spent in
lock sections.

Take a look at examples at
http://msdn.microsoft.com/msdnmag/is...Multithreading and in MSDN
also, if you haven't seen them yet.

HTH
Alex

"Charles Law" <blank@nowhere. com> wrote in message
news:%23gch7YmQ EHA.3988@tk2msf tngp13.phx.gbl. ..[color=blue]
> Hi Jon
>
> I have implemented a solution using SyncLock, Wait and Pulse, and all is
> well. My CPU time has gone down from 30% to nil, which always cheers me up
> :-)
>
> However, I am noticing some odd behaviour. My previous solution used a do
> loop, with DoEvents in it and a test for my flag, whereas the current
> solution calls
>
> Monitor.Wait(my flag, 100)
>
> to wait for 100ms before returning.
>
> Using DoEvents, I could click on a checkbox on-screen and it would change
> state with each click. Now, using Monitor.Wait, I have to click the box
> several time before it changes state. It's as if the UI is not getting[/color]
time[color=blue]
> to service the clicks.
>
> Is that behaviour you would expect using Monitor.Wait?
>
> At this point I have three threads running: the main UI thread, a comms
> thread that listens to the serial port, and a thread that waits for[/color]
service[color=blue]
> requests from the comms thread. The comms thread call[/color]
Monitor.Pulse(m yflag)[color=blue]
> whilst the service request thread call Monitor.Wait. On that basis, I[/color]
would[color=blue]
> expect the UI thread to be unhindered, but that does not seem to be the
> case.
>
> Charles
>
>
> "Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
> news:MPG.1b1d34 94c79a7dd298a9e b@msnews.micros oft.com...[color=green]
> > Charles Law <blank@nowhere. com> wrote:
> >
> > <snip>
> >[color=darkred]
> > > Sounds good, but now I have to periodically check for the flag in the[/color][/color]
> main[color=green][color=darkred]
> > > thread. That sounds an awful lot like polling to me, and I don't want[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> > > waste time polling.
> > >
> > > How can I catch the flag in the main thread when it changes, without[/color][/color]
> having[color=green][color=darkred]
> > > to sit and wait for it?
> > >
> > > As usual, any suggestions about how else to do this are always[/color][/color][/color]
welcome,[color=blue][color=green][color=darkred]
> > > however radical.[/color]
> >
> > I'm afraid I didn't follow your example very closely, but it sounds
> > like you basically want Monitor.Wait and Monitor.Pulse.
> >
> > I've got an unfinished article which talks about them (and other
> > things) - it's at
> > http://www.pobox.com/~skeet/csharp/multithreading.html
> >
> > There's more to come when I get round to it, but the bit in "More
> > Monitor methods" described Wait and Pulse.
> >
> > (You could also use ManualResetEven t or AutoResetEvent. )
> >
> > --
> > Jon Skeet - <skeet@pobox.co m>
> > http://www.pobox.com/~skeet
> > If replying to the group, please do not mail me too[/color]
>
>[/color]

[Jon Skeet [C# MVP]]

Re: Waiting on a Thread - Revisited

Charles Law <blank@nowhere. com> wrote:[color=blue]
> I have implemented a solution using SyncLock, Wait and Pulse, and all is
> well. My CPU time has gone down from 30% to nil, which always cheers me up
> :-)
>
> However, I am noticing some odd behaviour. My previous solution used a do
> loop, with DoEvents in it and a test for my flag, whereas the current
> solution calls
>
> Monitor.Wait(my flag, 100)
>
> to wait for 100ms before returning.
>
> Using DoEvents, I could click on a checkbox on-screen and it would change
> state with each click. Now, using Monitor.Wait, I have to click the box
> several time before it changes state. It's as if the UI is not getting time
> to service the clicks.
>
> Is that behaviour you would expect using Monitor.Wait?
>
> At this point I have three threads running: the main UI thread, a comms
> thread that listens to the serial port, and a thread that waits for service
> requests from the comms thread. The comms thread call Monitor.Pulse(m yflag)
> whilst the service request thread call Monitor.Wait. On that basis, I would
> expect the UI thread to be unhindered, but that does not seem to be the
> case.[/color]

I'm not sure what you're doing in your UI thread - I would strongly
suggest not having a Monitor.Wait in your UI thread at all, nor having
calls to Application.DoE vents(). The UI thread should solely be for UI
actions.

What are you doing on the UI thread other than short-running UI
operations?

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Charles Law]

Re: Waiting on a Thread - Revisited

Hi Alex

What I was trying to say was that there is no Wait in my UI thread. That is
why I am surprised by the effect. The threads that use monitor are the comms
thread and the service request thread.

Charles


"AlexS" <salexru2000NO@ SPAMsympaticoPL EASE.ca> wrote in message
news:OZzL$gmQEH A.620@TK2MSFTNG P10.phx.gbl...[color=blue]
> Hi, Charles
>
> if you use Wait on UI thread - that's the reason. Wait passes effectively
> control out of calling thread, so it's even worse than DoEvents in this
> respect. If you use lock on UI thread on same object(s), which are used in
> Monitor.Wait - that's one additional reason.
>
> I lost track of original questions/answers, so can recommend only - remove
> Wait from UI thread and check what and where you lock. Attach event to
> thread object, assign UI thread delegate to event when constructing thread
> and use Pulse in UI thread and Wait in worker thread. Minimize time spent[/color]
in[color=blue]
> lock sections.
>
> Take a look at examples at
> http://msdn.microsoft.com/msdnmag/is...Multithreading and in MSDN
> also, if you haven't seen them yet.
>
> HTH
> Alex
>
> "Charles Law" <blank@nowhere. com> wrote in message
> news:%23gch7YmQ EHA.3988@tk2msf tngp13.phx.gbl. ..[color=green]
> > Hi Jon
> >
> > I have implemented a solution using SyncLock, Wait and Pulse, and all is
> > well. My CPU time has gone down from 30% to nil, which always cheers me[/color][/color]
up[color=blue][color=green]
> > :-)
> >
> > However, I am noticing some odd behaviour. My previous solution used a[/color][/color]
do[color=blue][color=green]
> > loop, with DoEvents in it and a test for my flag, whereas the current
> > solution calls
> >
> > Monitor.Wait(my flag, 100)
> >
> > to wait for 100ms before returning.
> >
> > Using DoEvents, I could click on a checkbox on-screen and it would[/color][/color]
change[color=blue][color=green]
> > state with each click. Now, using Monitor.Wait, I have to click the box
> > several time before it changes state. It's as if the UI is not getting[/color]
> time[color=green]
> > to service the clicks.
> >
> > Is that behaviour you would expect using Monitor.Wait?
> >
> > At this point I have three threads running: the main UI thread, a comms
> > thread that listens to the serial port, and a thread that waits for[/color]
> service[color=green]
> > requests from the comms thread. The comms thread call[/color]
> Monitor.Pulse(m yflag)[color=green]
> > whilst the service request thread call Monitor.Wait. On that basis, I[/color]
> would[color=green]
> > expect the UI thread to be unhindered, but that does not seem to be the
> > case.
> >
> > Charles
> >
> >
> > "Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
> > news:MPG.1b1d34 94c79a7dd298a9e b@msnews.micros oft.com...[color=darkred]
> > > Charles Law <blank@nowhere. com> wrote:
> > >
> > > <snip>
> > >
> > > > Sounds good, but now I have to periodically check for the flag in[/color][/color][/color]
the[color=blue][color=green]
> > main[color=darkred]
> > > > thread. That sounds an awful lot like polling to me, and I don't[/color][/color][/color]
want[color=blue]
> to[color=green][color=darkred]
> > > > waste time polling.
> > > >
> > > > How can I catch the flag in the main thread when it changes, without[/color]
> > having[color=darkred]
> > > > to sit and wait for it?
> > > >
> > > > As usual, any suggestions about how else to do this are always[/color][/color]
> welcome,[color=green][color=darkred]
> > > > however radical.
> > >
> > > I'm afraid I didn't follow your example very closely, but it sounds
> > > like you basically want Monitor.Wait and Monitor.Pulse.
> > >
> > > I've got an unfinished article which talks about them (and other
> > > things) - it's at
> > > http://www.pobox.com/~skeet/csharp/multithreading.html
> > >
> > > There's more to come when I get round to it, but the bit in "More
> > > Monitor methods" described Wait and Pulse.
> > >
> > > (You could also use ManualResetEven t or AutoResetEvent. )
> > >
> > > --
> > > Jon Skeet - <skeet@pobox.co m>
> > > http://www.pobox.com/~skeet
> > > If replying to the group, please do not mail me too[/color]
> >
> >[/color]
>
>[/color]

[Charles Law]

Re: Waiting on a Thread - Revisited

Hi Jon

I was halfway through a response about not having a wait in my UI thread
when it dawned on me what I am doing. I will have to rethink this.

Thanks.

Charles


"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1b1d6f 3be4a9788298a9f a@msnews.micros oft.com...[color=blue]
> Charles Law <blank@nowhere. com> wrote:[color=green]
> > I have implemented a solution using SyncLock, Wait and Pulse, and all is
> > well. My CPU time has gone down from 30% to nil, which always cheers me[/color][/color]
up[color=blue][color=green]
> > :-)
> >
> > However, I am noticing some odd behaviour. My previous solution used a[/color][/color]
do[color=blue][color=green]
> > loop, with DoEvents in it and a test for my flag, whereas the current
> > solution calls
> >
> > Monitor.Wait(my flag, 100)
> >
> > to wait for 100ms before returning.
> >
> > Using DoEvents, I could click on a checkbox on-screen and it would[/color][/color]
change[color=blue][color=green]
> > state with each click. Now, using Monitor.Wait, I have to click the box
> > several time before it changes state. It's as if the UI is not getting[/color][/color]
time[color=blue][color=green]
> > to service the clicks.
> >
> > Is that behaviour you would expect using Monitor.Wait?
> >
> > At this point I have three threads running: the main UI thread, a comms
> > thread that listens to the serial port, and a thread that waits for[/color][/color]
service[color=blue][color=green]
> > requests from the comms thread. The comms thread call[/color][/color]
Monitor.Pulse(m yflag)[color=blue][color=green]
> > whilst the service request thread call Monitor.Wait. On that basis, I[/color][/color]
would[color=blue][color=green]
> > expect the UI thread to be unhindered, but that does not seem to be the
> > case.[/color]
>
> I'm not sure what you're doing in your UI thread - I would strongly
> suggest not having a Monitor.Wait in your UI thread at all, nor having
> calls to Application.DoE vents(). The UI thread should solely be for UI
> actions.
>
> What are you doing on the UI thread other than short-running UI
> operations?
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

[Charles Law]

Re: Waiting on a Thread - Revisited

Alex

A correction. I have just realised that I have fallen victim of my own
attempt to oversimplify the problem. I am indeed using wait in my UI thread,
which is not what I had intended. The words drawing, board and back spring
to mind ;-)

Charles


"AlexS" <salexru2000NO@ SPAMsympaticoPL EASE.ca> wrote in message
news:OZzL$gmQEH A.620@TK2MSFTNG P10.phx.gbl...[color=blue]
> Hi, Charles
>
> if you use Wait on UI thread - that's the reason. Wait passes effectively
> control out of calling thread, so it's even worse than DoEvents in this
> respect. If you use lock on UI thread on same object(s), which are used in
> Monitor.Wait - that's one additional reason.
>
> I lost track of original questions/answers, so can recommend only - remove
> Wait from UI thread and check what and where you lock. Attach event to
> thread object, assign UI thread delegate to event when constructing thread
> and use Pulse in UI thread and Wait in worker thread. Minimize time spent[/color]
in[color=blue]
> lock sections.
>
> Take a look at examples at
> http://msdn.microsoft.com/msdnmag/is...Multithreading and in MSDN
> also, if you haven't seen them yet.
>
> HTH
> Alex
>
> "Charles Law" <blank@nowhere. com> wrote in message
> news:%23gch7YmQ EHA.3988@tk2msf tngp13.phx.gbl. ..[color=green]
> > Hi Jon
> >
> > I have implemented a solution using SyncLock, Wait and Pulse, and all is
> > well. My CPU time has gone down from 30% to nil, which always cheers me[/color][/color]
up[color=blue][color=green]
> > :-)
> >
> > However, I am noticing some odd behaviour. My previous solution used a[/color][/color]
do[color=blue][color=green]
> > loop, with DoEvents in it and a test for my flag, whereas the current
> > solution calls
> >
> > Monitor.Wait(my flag, 100)
> >
> > to wait for 100ms before returning.
> >
> > Using DoEvents, I could click on a checkbox on-screen and it would[/color][/color]
change[color=blue][color=green]
> > state with each click. Now, using Monitor.Wait, I have to click the box
> > several time before it changes state. It's as if the UI is not getting[/color]
> time[color=green]
> > to service the clicks.
> >
> > Is that behaviour you would expect using Monitor.Wait?
> >
> > At this point I have three threads running: the main UI thread, a comms
> > thread that listens to the serial port, and a thread that waits for[/color]
> service[color=green]
> > requests from the comms thread. The comms thread call[/color]
> Monitor.Pulse(m yflag)[color=green]
> > whilst the service request thread call Monitor.Wait. On that basis, I[/color]
> would[color=green]
> > expect the UI thread to be unhindered, but that does not seem to be the
> > case.
> >
> > Charles
> >
> >
> > "Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
> > news:MPG.1b1d34 94c79a7dd298a9e b@msnews.micros oft.com...[color=darkred]
> > > Charles Law <blank@nowhere. com> wrote:
> > >
> > > <snip>
> > >
> > > > Sounds good, but now I have to periodically check for the flag in[/color][/color][/color]
the[color=blue][color=green]
> > main[color=darkred]
> > > > thread. That sounds an awful lot like polling to me, and I don't[/color][/color][/color]
want[color=blue]
> to[color=green][color=darkred]
> > > > waste time polling.
> > > >
> > > > How can I catch the flag in the main thread when it changes, without[/color]
> > having[color=darkred]
> > > > to sit and wait for it?
> > > >
> > > > As usual, any suggestions about how else to do this are always[/color][/color]
> welcome,[color=green][color=darkred]
> > > > however radical.
> > >
> > > I'm afraid I didn't follow your example very closely, but it sounds
> > > like you basically want Monitor.Wait and Monitor.Pulse.
> > >
> > > I've got an unfinished article which talks about them (and other
> > > things) - it's at
> > > http://www.pobox.com/~skeet/csharp/multithreading.html
> > >
> > > There's more to come when I get round to it, but the bit in "More
> > > Monitor methods" described Wait and Pulse.
> > >
> > > (You could also use ManualResetEven t or AutoResetEvent. )
> > >
> > > --
> > > Jon Skeet - <skeet@pobox.co m>
> > > http://www.pobox.com/~skeet
> > > If replying to the group, please do not mail me too[/color]
> >
> >[/color]
>
>[/color]

[Jon Skeet [C# MVP]]

Re: Waiting on a Thread - Revisited

Charles Law <blank@nowhere. com> wrote:[color=blue]
> What I was trying to say was that there is no Wait in my UI thread. That is
> why I am surprised by the effect. The threads that use monitor are the comms
> thread and the service request thread.[/color]

So what is the UI thread doing, do you know? It might be worth breaking
into the app in debug mode while it's being unresponsive, and see if
you can see where the UI thread is.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Re: Waiting on a Thread - Revisited

Charles Law <blank@nowhere. com> wrote:[color=blue]
> A correction. I have just realised that I have fallen victim of my own
> attempt to oversimplify the problem. I am indeed using wait in my UI thread,
> which is not what I had intended. The words drawing, board and back spring
> to mind ;-)[/color]

:)

Don't worry about it - threading is a tough nut to crack, and you
*always* have to be wary. (I squashed a deadlock bug today and felt
rather victorious - until I started wondering whether we've got any
others.)

If we can help any more, just ask - it often helps just to post your
potential plan of action, as then you tend to spot the flaws (if any!)
about 10 seconds after posting it. At least, that's my experience...

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Charles Law]

Re: Waiting on a Thread - Revisited

Hi Jon

I have been confusing two different bits of kit attached to the serial
ports. One is a long standing item that has a complicated path between UI
and comms. The other, which I added a couple of days ago, has a more direct
connection, and uses an ASCII protocol. The latter is the one that raises
service requests, and seems to be working fine. Having added it
successfully, I returned to the original item and thought I would 'improve'
it's operation by using SyncLock and Monitor.Wait/Pulse. What I failed to
appreciate was that the old kit was communicating straight off the UI
thread, so when I changed to using Monitor.Wait instead of a timeout loop
with DoEvents, the UI suddenly started behaving badly.

....

Actually, now I think about it, I was right the first time: my UI thread
does _not_ use Wait. I have a polling thread as well (you must think I don't
know what I am doing). The polling thread sends commands to the original
item and waits for a reply. It waits using Monitor.Wait and the comms thread
pulses to alert the polling thread when a reply has been received.
Therefore, my UI thread is just sitting in the normal message loop, waiting
for the user to click something.

When I use the timeout loop with DoEvents in the polling thread, the UI is
responsive. When I use Monitor.Wait in the polling thread, the UI starts to
play up, taking several clicks to change a checkbox state. [I should add at
this point that with each click of the checkbox, a command is sent to the
serial port and on to the external hardware. The polling thread retrieves
status information, one bit of which indicates whether the checkbox should
be checked or not. I have to click several times before the hardware sends a
status message showing that it received the command].

What is odd is that the it works smoothly when I use the timeout loop with
DoEvents, but not when I use Monitor.Wait.

I think I am going to have to draw a picture of what is happening - this is
doing my head in.

Charles


"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1b1dd1 9fd80ff6f598aa1 2@msnews.micros oft.com...[color=blue]
> Charles Law <blank@nowhere. com> wrote:[color=green]
> > What I was trying to say was that there is no Wait in my UI thread. That[/color][/color]
is[color=blue][color=green]
> > why I am surprised by the effect. The threads that use monitor are the[/color][/color]
comms[color=blue][color=green]
> > thread and the service request thread.[/color]
>
> So what is the UI thread doing, do you know? It might be worth breaking
> into the app in debug mode while it's being unresponsive, and see if
> you can see where the UI thread is.
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

[Cor Ligthert]

Re: Waiting on a Thread - Revisited

Hi Charles,

And comes my solution again in picture?

I have thought your problem over as well, now I know I do it like that I
told, however I use the listview as the stack container.

And it works very fine.

Cor