Len, and Don, and everyone else who contributed to this
thread,
Thanks - a bunch. I am in the initial design phase of this
major project,
so I have the freedom to actually do it right. I was
already planning on
using some multithreading for parts of this project. I will
probably do
more - the debugging won't be as bad because I am very
familiar with most of
the hardware already, having programmed for it before. Your
responses have
taught me a lot and made me think from different
perspectives.
Thanks again,
Kelly
-----Original Message-----
From: Discussion of writing applications and components
using Visual Basic
.NET [mailto:VBDOTNET DISCUSS.DEVELOP.COM] On Behalf Of Len
Porzio
Sent: Tuesday, April 18, 2006 12:41 PM
To: VBDOTNETDISCUSS.DEVELOP.COM
Subject: Re: [VBDOTNET] Delay function in .net
> Is this even possible? (No DoEvents)
Without using doevents, you would be forced to put all
externally
blocked operations in their own seperate thread. Which is
actually a
good idea but a big change in your programming model since
now you
must redesign for asynchronous coordination.
(The problem is where does a process go when it's done
doing it's job
and even so has any state changed in the mean time.)
So assuming you don't intend to put every motor or switch
process in
its own thread (baby steps) then DoEvents is the only way to
force
the UI thread to process pending events (like mouse and
keyboard
activity). Otherwise it waits until the application is
idle.
So let's say you're in a tight DO LOOP waiting for a motor
response.
That's not idle, hense no time to process events. OK now
let's say
you sleep to reduce CPU load. Well that makes it easier for
outside
processes and applications to do their thing but the UI
thread is
asleep so it can't respond to events. Then when it comes
out of sleep
the load is back on again and so again it's not idle.
So the best of both worlds is to sleep(1ms) and doevents.
This forces
the UI to process events and it forces its thread to step
aside in the
event another process is waiting for CPU time. This tiny
sleep crack
is often very critical when you have various layers of
software like
WonderWorks or ActiveX Servers talking to external devices.
I encourage you to think about redesign and using threaded
devices
when you have the time (way-cool). But shreading
(multithreading) is
an order of magnitude harder to debug for a bunch of
reasons. Some
bugs, like those that are event sensitive, can't be trapped
in a
debugger environment because the events often get dropped.
So make
sure you have the time to do it right and go slowly one
device at a
time.
- Len
On 4/18/06, Don Edwards <don.edwardsseattle.gov> wrote:
> From: Kelly Baker <kbakerHOWARD-IND.COM>
>
> >If it were only meters and other equipment that
could be run/status
> >checked asynchronously, I would agree with you.
>
> That's when you would NOT need to do what I'm
suggesting.
>
> >But the majorityof my use of a Delay function is in
IO, which must
> >be synchronous. I just need to make sure the user
interface, and
> >other non-IO related stuff, is not frozen.
>
> That's why you want to move the Delay functions into
separate
> object-specific threads. Each object is responsible for
knowing
> when its physical device is through with its most
recent instruction,
> and whether this is a good time to send a new
instruction. Thus
> the GUI doesn't have to deal with this - it only has
to know not to
> send a command to an object whose device isn't ready
to receive
> one, and it can ask the object about that.
>
> And if the GUI wants to send a device a *series* of
commands,
> to be executed as quickly as possible without further
GUI
> involvement (unless something is seen to go wrong of
course),
> then you need some sort of a queue. I'm suggesting
that this
> queue itself be an object that looks like - and wraps
around -
> the device object.
>
> ===================================
> This list is hosted by DevelopMentor(r) http://www.develop.com
>
> View archives and manage your subscription(s) at
http://discuss.develop.com
>
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
|