I misunderstood some things before, maybe I still misunderstand some things. Plunging ahead anyway...
1. The "real-time" aspect of this app isn't very demanding. Accumulating an array of 86 values once a second for an hour (3600 seconds) is pretty trivial.
2. You state that you then can flush this buffer and do some kind of 1 hour averaging analysis that you store for some further historical trending purpose. Again, no biggie.
3. You then kinda lost me with the following:
Then also I have to store the analyzed data. For example, storing the 1h averages from 1 year ago. This will be a 87600×86 buffer that when the first year is reached, the oldest value has to be removed from one extreme and the new added at the other one.
First, there are 24*365=8760 hours in a year, not 87600, so you've overestimated your buffer size needs by 10x. Second, this sounds like the kind of thing you only need to handle once per hour. Again, I don't see why performance needs to be such a big concern.
Third, you describe this as though the program needs to build up this "1 year of hourly averages" buffer in memory by running continuously for a year or more. That seems like a very unsafe approach. While an actual database would be better, you could pretty easily handle this via something as simple as ASCII files.
I would imagine laying out a combo of file naming convention and folder structure first. The "real-time" part of your program would store average data once per hour. At program startup, I'd go find the relevant files and fill my lossy circular buffer with the most recent 1 year of hourly data. An hour later, I'd replace the oldest with my newest. Etc.
On another note, I very much agree with the following comments from wiebe about your use of VI server and cloned FGV's.
wrote: You mean that is a bad thing to create a preallocated clone of FGV and forward its reference wire?
wrote: That would work, technically... But it's sooo complicated (to make and to work with), compared to a wire\value, or even a wire\ref, solution.
It just seems like complexity without corresponding payoff. It sounds like you need no more than 2 distinct buffers -- one to accumulate every second for up to an hour, one to update every hour to hold exactly 1 year worth of hourly averages. From where I sit, it seems both could be handled pretty directly with queues without the FGV layer.
If you're really intent on managing 2 distinct buffers with 1 common set of code, you might take this as an opportunity to try LVOOP. What you've coded to handle reentrant clones with VI Server is more complicated than what it'd take to make a class-based implementation. Much of the wiring would probably look just about the same with object wires in place of the VI refs.
-Kevin P