Re: Best way to design multithreading application

On Sep 27, 5:28 pm, Peter Duniho <NpOeStPe...@xxxxxxxxxxxxxxxx> wrote:
Note: the UI is generally going to be mostly CPU-bound. So a thread
"tied to UI" is really "tied to CPU". It will compete with any other
thread also CPU-bound.

Good point. Maybe that affirms it's best to at least separate out the
file writing, that may be the most optimization speed-wise I'll be
able to do.

On a multi-core system, there's a high likelihood that you can use
threading of some sort of allow the data acquisition thread to cooperate
with the UI update thread. That is, allow both the data acquisition
thread and the UI thread to execute simultaneously, each on a different
core.

That's pretty much what I'm shooting for, but there will be cases it
runs on one core, but will still need to acquire data while UI is
updating. I guess threads will solve both situations.

That said, if you are using USB then I'm guessing you have some kind of
async method available to do the data acquisition i/o. This means that
you may not need any explicit threads additional to the main UI thread.
Instead, you can use a Forms.Timer to regulate the data acquisition
intervals, and use a BeginXXX style method to request data. It will
complete using a different thread, so it's still a multi-threaded
solution, but it takes advantage of the thread pool and whatever
underlying i/o mechanism is available (probably i/o completion ports,
but without knowing the specifics of your code, I can't say...even
knowing the specifics, I might not be able to say :) ).

Unfortunately, there is no async. The only interface we have to the
device is a single call to an OEM DLL, which takes a single
acquisition (30ms) and returns the data as a double[2048]. Thus, any
async methods we have to develop ourselves. Right now there is a loop
for acquiring, set up like this:
while(DateTime.now < NextAcqEndDate)
addToMainArray(OEM_DLL.acquireData());

So, for 1 second acquisitions, this will keep adding the result to an
array, and at the end of this loop it averages the array over number
of counts (the number of times acquireData() is called), and returns
it. acquireData() takes 30ms, and that's the portion we would like to
keep going. As you can see, in a linear algorithm, this thing runs for
1 second, stops acquiring, and finishes all the other updates. Due to
the nature of chemical detection, we'd obviously like to keep this
going as long as possible, even if it has to call acquireData() in
discrete chunks, so long as the chunks are not 1s gaps like now.

I have never used the BeginInvoke and BeginWrite methods, so that
alone may offer a good start to this problem.

I have a more-detailed reply to your other message. I replied here just
to clarify some points; hopefully the other post provides the details
you really need to get the clarification you want.

Yes, the other message helps a lot too... I may take a few days to
digest this; luckily this is long-term. I really appreciate your input
here, it's not the easiest subject to just jump into. :)

Dave

.

Loading