Re: Best way to design multithreading application

On Sep 27, 7:32 pm, Peter Duniho <NpOeStPe...@xxxxxxxxxxxxxxxx> wrote:
What does it do with the average? What else is done with the array? Is
that what you write to the file?

As far as the average goes, it seems to me that it would be better to
calculate the sum for the average as you get the data. The addition is
a trivial operation, and it will reduce the number of times you
enumerate the array by one.

Of course, if _all_ you're doing is calculating the average then
obviously you don't even need the array. So I'm taking as granted that
you do something else with that data besides calculating the average.

When I saw "average", I mean each individual point in the data array.
This is why more iterations of data acquisition yield better
statistics. So the entire 2048 elements are iterated every 30ms
acquisition to sum it, and then once more at the end to average each
element by time. Once we get this average array, we send it to a C dll
that does some tricky processing and returns some data we use to
determine alarm states (detection of a chemical compound). That data
is what we write to each file, along with the averaged array. Once the
file is written, we update the UI with two charts, one being the
averaged array, and another representing the data returned from that
special DLL.

Based on your description, it sounds as though at the least you should
be able to use BeginInvoke() rather than having a separate thread for
dealing with the UI. BeginInvoke() would pass whatever data is useful
for updating the UI, and then the actual work would wind up occuring on
the UI thread itself.

So perhaps instead of setting up a secondary queue for UI operations,
I can simply call BeginInvoke with only the data it needs to update
the charts/tables?

Whether BeginWrite would be helpful or not, I'm not entirely sure. I
just noticed in the docs that it says that for writes shorter than 64KB,
using BeginWrite could actually reduce performance.

I suspect that this applies only to the i/o performance itself and so
assuming you're not pushing the limits of the disk bandwidth (and if
you're only generating 8K of data per second, you shouldn't be :) ) the
architectural gain should be well worth any minimal performance
reduction (noting that the performance reduction wouldn't affect the
data acquisition, just how fast the data gets to the disk).

We're not really pushing the limits of the disk bandwidth, and the
entire write takes about 200ms, so I'm not really looking to gain
performance there in terms of the I/O operation itself. But, I figure
that by putting it on a separate thread, it will at least be allowing
another thread to have some CPU time while it's doing disk I/O, so
there might be a small performance gain from that (maybe not
noticeable), compared to the system now where it sits there waiting
for it to happen. Our files wind up being 72KB on the disk, so they
are right at that crossover of performance. So, I think it might be
good to stick with the original plan of a separate thread for disk I/O
even if it's just a few lines of code executing each time.

Right now our biggest problem is obviously the charting, so perhaps
starting with one thread for everything else and using the form's
thread via BeginInvoke would be the best place to start, and go from
there as needed.

Thanks again,
Dave


.

Relevant Pages

  • Re: Choosing the proper disk setup. I need help and advice.
    ... no amount of hardware will fix the problem. ... something like 18 disk spindles across 4 SCSI channels. ... Don't fret too much about disk I/O most arrays go much faster than the ... > inadequeate CPU speed, or network I/O as the bottleneck. ...
    (microsoft.public.windows.server.general)
  • Re: store.exe memory usage
    ... Ed Crowley MVP ... another hard disk, which of the following options would improve the disk I/O ... >> IMAP is not MAPI. ...
    (microsoft.public.exchange.admin)
  • Re: COTS application suggestions for auditing
    ... The performance impact is probably caused by having to perform two disk ... i/o's for every disk i/o ... > success audit across the board on the systems' files (not ...
    (microsoft.public.security)
  • Re: Exchange performance help
    ... about 90% of the time the popup is caused by disk I/O ... How many users are on the server and how many physical disks make up the ... We are getting the 9548 warnings about master sid approximately 15-30 ...
    (microsoft.public.exchange.admin)
  • Re: How to stop Invoked code running immediately after ShowDialog() closes
    ... Whilst the dialog is displayed a worker thread that monitors files ... changing on disk calls BeginInvoke() on the Form. ...
    (microsoft.public.dotnet.languages.csharp)