Re: Time Critical Process in .NET

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Charles Law (blank_at_nowhere.com)
Date: 03/25/05 

Date: Fri, 25 Mar 2005 13:36:14 -0000

I have been experimenting some more, and have created a sample that queues
updates for a timer. The timer polls every second, and if it finds messages
in the queue it locks the queue, removes them all to an array, and unlocks
the queue. It then writes the messages to the rich text box and exits.

The queue is filled by a thread that just loops 1000 times, each time
locking the queue, adding a message and releasing the lock. So far so good.

If the FillQueue process is allowed to loop freely, it fills the queue in no
time at all (< 1 second). The timer then fires and takes 5 seconds to write
all the messages to the rich text box.

If the FillQueue process has a Sleep(20) in it (which is more representative
of my real-world scenario), then it takes 31 seconds to fill the queue, and
the timer function puts the messages on the screen (in a burst every
second), completing within 1 second of the FillQueue process finishing.

My second sample uses BeginInvoke. A class is created and its DoStuff method
is run on a new thread. DoStuff loops 1000 times, raising an event each time
round the loop. The event handler uses BeginInvoke to marshal to a function
that writes a message to a rich text box.

If DoStuff loops freely, it completes the loop in < 1 second. The screen
updates finish 5 seconds later.

If the DoStuff loop contains a Sleep(20), then it takes 31 seconds to
complete the loop, and the screen updates finish at exactly the same time.

>From this simple test, it would seem to me that there is actually nothing to
choose between the two methods where speed is concerned. I haven't tried the
test with a loop count of 10,000, but I suspect that the results will be
comparable, and that the overriding issue will be the degradation of
performance of the rich text box as it fills up, as indicated by my earlier
test.

Following on from your other reply, I take the point about a listview
limiting the user's ability to copy sections of the output. The listview
also doesn't output as rtf, which is currently a nice feature because I can
retain the colour coding of the output. If there were a way of converting a
memory stream to rtf then that would be nice.

With regard to maintaining the rtf in a string builder, I have looked at
hand crafting rtf and it seems a lot to get to grips with. It also isn't as
generic a solution as I would like. I will look at this further though.

The idea of creating my own control has its appeal, because then I would
have total control. I will have a quick play and see where I get to.

Thanks.

Charles

"CMM" <CMM@discussions.microsoft.com> wrote in message
news:CB444FB8-B89B-4778-86BB-30A74A3F2DB7@microsoft.com...
> Your problems seems to be basically this:
>
> Your rich edit UI update is too sloooow. BeginInvoke queues up calls to
> maintain thread safety. The best solution IMHO is the "polling" technique
> I
> suggested earlier.
>
> 1) Worker thread SyncLocks a stack and pushes stuff into it.
> 2) UI Timer set at a reasonable interval (1 second maybe) SyncLocks the
> stack, pops stuff out (*without* updating the UI I may add!) and lets go
> of
> the SyncLock and then updates the UI... very nice, quick, and elegant.
> Much
> better than updating the UI in realtime and on-demand... which apparently
> is
> not working the way you want it to.
> 3) Everyone is happy. At most the UI is a second or so behind the
> workthread's actual status.
>
>
> "Charles Law" wrote:
>
>> I can't remember where I got up to with this thread, so this is a general
>> update on the problem.
>>
>> I ran the application again this morning, against the real equipment. The
>> time critical parts of the process now seem to be more stable, after
>> implementing some of the suggestions, but at the severe detriment to the
>> UI.
>> As mentioned before, the background process raises events when it wants
>> to
>> notify the UI that something has happened, and the event handler marshals
>> the event onto the UI thread, using a delegate and BeginInvoke, and
>> appends
>> the message to a rich text box.
>>
>> The problem is now that the screen appears to be updating at a reasonable
>> pace, but it is clearly lagging a long way behind the messages being
>> supplied to it. At its worst, the background process finished, and it
>> took
>> over five minutes for the screen to catch up. FIVE MINUTES! I think I
>> have
>> got my pattern wrong here. I don't mind the screen lagging slightly
>> behind,
>> but five minutes is just silly.
>>
>> Going back to basics, I want to (need to) capture the messages passed in
>> all
>> the events that the background thread raises, and I want to maintain a
>> display of these messages. Some messages will be coloured red to make
>> them
>> stand out to the user, which is why I have used a rich text box.
>>
>> Is there a better pattern for this type of application?
>>
>> Incidentally, I ran this on a 3.0 GHz P4 Dell laptop, not the slower
>> Celeron m/c, so it will be much worse on the intended target m/c.
>>
>> Charles
>>
>>
>> "Charles Law" <blank@nowhere.com> wrote in message
>> news:uuG%231YhKFHA.508@TK2MSFTNGP12.phx.gbl...
>> > Hi guys
>> >
>> > I have a time critical process, running on a worker thread. By "time
>> > critical", I mean that certain parts of the process must be completed
>> > in a
>> > specific time frame. The time when the process starts is not especially
>> > important, but it must be complete within a small number of seconds.
>> >
>> > The operations I am performing do not take a long time (hundreds of
>> > milliseconds), but as each part of the process is complete, my worker
>> > thread raises an event that is handled by the UI thread, to update a
>> > rich
>> > text control with details of the completed operation. I am using a rich
>> > text box so that when a failure occurs I can colour the message red.
>> >
>> > The problem I have is that sometimes, for no apparent reason, a step in
>> > my
>> > process takes an inordinate amount of time, e.g 2.5 seconds instead of
>> > perhaps 300 ms. When this happens, the complete process overruns my
>> > time
>> > frame, and it has to be repeated. When I repeat the process there is
>> > every
>> > chance that it completes in a realistic time, and all is well. If I
>> > stop
>> > outputting to the screen, I do not get the problem.
>> >
>> > When updating the screen on the UI thread, I use BeginInvoke, to
>> > marshal
>> > the operation to the correct thread, and so as not to hold up the
>> > worker
>> > thread, but this does not seem to help.
>> >
>> > I realise that Windows (XP in this case) is not the ideal o/s for this
>> > type of application, but does anyone have any ideas about how I could
>> > make
>> > my application more deterministic? I am not certain what is going on in
>> > these 2.5 seconds, so it might be useful if I could find out, but I am
>> > not
>> > sure how I would do that.
>> >
>> > TIA
>> >
>> > Charles
>> >
>> >
>>
>>
>>

Relevant Pages

  • Re: 2-player game, client and server at localhost
    ... A synchronous queue is a thread-safe queue. ... You'd push event updates to it from the communication thread, and in the update thread, WHICH IS ALWAYS RUNNING, you'd check the queue each loop to see if there was anything new. ... I'm reading 1 byte from client every time before sending new update to ...
    (comp.lang.python)
  • Re: Delaying events for fixed amounts of time.
    ... amount of time after the *FIRST* event with a given key arrives. ... I have anything Windows has to offer. ... Pause for, say, 250ms each time through the loop ... Have a queue of keys, each time a new key arrives, add it to the end ...
    (comp.programming.threads)
  • Re: Threading help... threads???
    ... it appears as if you have an endless loop. ... remove the call record from the queue and make the call. ... End Sub ... 'derived classes must override. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Delaying events for fixed amounts of time.
    ... amount of time after the *FIRST* event with a given key arrives. ... Process events as timers expire. ... Pause for, say, 250ms each time through the loop ... Have a queue of keys, each time a new key arrives, add it to the end ...
    (comp.programming.threads)
  • Re: multithreaded dialog application
    ... receiving thread is to queue up a computation request to an I/O Completion Port. ... Note that one possible solution in the case of multiple updates is ... the "write pipe" model, where a thread handles all the updates, let's say to a single ... Human perception rates being what they are, "real time" ...
    (microsoft.public.vc.mfc)