Philosophical Fortran Question.

[JohnNichols]

I have spent some time playing with a program that is multithreaded and needs to be designed it so never stop collecting data. 

But it appears the best way to let the second thread communicate with the first thread is through a "global" variable, like common blocks do for functions, meaning subroutines as well if the comm is bidirectional.  

But the problem with global variables is like the problem with common blocks anyone can change them so there is a QA and control issue. 

Is there something here I am missing

[jimdempseyatthecove]

You can use GET/SET procedures that restrict which thread can perform the SET.

You could place the collected data into Thread Local Storage .AND. at startup each thread adds the address of its copy to the data collector thread. Then as each new datum arrives, the collector thread updates all the other copies. If an ancillary thread wants to muck-up its copy, so be it.

 "a program that is multithreaded and needs to be designed it so never stop collecting data"

You will need to assure that the data collecting is performed in a different process than that of the consumer threads/processes. Note, any thread in a single process that crashes, takes down the entire process. The aforementioned copies can be passed via shared memory or memory mapped file.

Jim Dempsey

Jim Dempsey

[JohnNichols]

The challenge arose because to get to NASA TRL 9, you need to prove the program essentially operates in "a space" alone and not "stopping" for a year.  This is the new normal request we get and the client has no idea what they are asking for, whether it is 3, 4, 5, 6, 7, 8, 9

If you are using Intel NUC's LINUX or Windows and a standard compiler, you have no chance of doing that without a lot of ancillary watching code and even then you need to define "what is an acceptable lost data rate." 

Yes we separate the processes,  but the problem is not just our stuff it is the outside world.  

I have one process that has run with minor problems for 2 years, then I struck an error that the Fortran program cannot cope with, the off site server people turned off our database by mistake and did not tell us.  Now I have to put in code to catch that error. 

it is challenging. 

I have  a NUC, a Fortran compiler and a client who wants TRL 9, then you need to tell them - 3 years min,  at least 2.5 of those are test and fail.   And in the 3 years the NUC has to be updated, so does the OS and the compiler.  And then there are the bad guys. 

All to keep two simple processes running using FFT code. 

[jimdempseyatthecove]

So you need:

1) A power supply/supplies that can run for the year with/without an external source

2) Local storage with sufficient capacity for the data collection (in the event the upload is interrupted)

3) Redundant local storage in the event primary local storage fails

4) Consider an O/S-less system (embedded) .OR. an O/S that you can turn off automatic updates (and O/S periodic "QoS" transmissions to O/S provider)

Jim Dempsey

[JohnNichols]

A power supply/supplies that can run for the year with/without an external source

::  Does not exist, there are always failures, we have failed all over the world, you can get close, but no-one gets power without interruption for a year at a remote location.

Local storage with sufficient capacity for the data collection (in the event the upload is interrupted)

:: We cannot store the data - there is not a HD big enough, we store the critical  results in MYSQL database which covers almost all external losses of storage

Redundant

:: actually a NUC with an SSD does not fail in a year - this is not a problem, remember this is a statistical thing - the only two companies I trust are Intel and the modem company, every one else fails. 

4. The Italians spent a fortune and did this with the system - they had enough power to run it for one minute in an hour.  

The real problem is siloing. 

[JohnNichols]

Jim:

The FFT in the Fortran is not the problem, but:

I am sorry we failed to get your data because:

1. It was raining and we did not have raincoats

2. The PC battery died -

3. It was hot and we went and got a drink

4. The maintenance guy switched off the power to the bridge and we did not realize

5. We are sorry the piece of equipment is covered by warranty, well except that argument took 2 years

6. We left it all assembled inside the bridge,. Did you not realize that the bridge is a Faraday cage and the cell phone was supposed to be externally attached, that is why it was next to the hole in the bridge structure?  What is a Faraday cage? We have permission to go back in 6 months.  

7. That hole is very deep, that structure is very tall, I am afraid of heights, water, dogs, cats and mice

8. It was a very big snake. 

9. I thought you said one minute, we did a minute at each location.  I said eight.  

10. We want to do it inside, it is hot outside,  you cannot there is a pump running at 35Hz in the corner and it will stuff up the FFT's, that argument took 8 hours to prove in a world class lab. 

11. Our accelerometer is very good!  We paid 10 dollars for it.  Ok, What is your reading on the thermal layer?

What is the thermal layer, we only see a straight line, 

12. honest, we hit it softly with a small sledge hammer to get the natural freq and the building collapsed, true story happened to a friend in '94.