I would move all things related to the file to the consumer loop. Do you ever want to stop logging, but continue acquiring data, until sometime later you start logging again?
In your producer loop, send two things, the data and a command enum This would be a cluster of enum and data. The enum can have certain commands, like start logging, Log Data, stop logging. or even new file. Possible one more which is Stop Program.
Let your consumer loop dequeue that cluster (without a timeout), and also maintain a boolean on a shift register that signifies whether loggin is currently active.
When you press the record button, let is queue up a Start Logging button and data. When the consumer loop gets that, it executes a case of the case structure that creates the file name and opens the file, stores it in the shift register, and also puts a True value on the Logging? shift register. When it gets a Log data command, it goes into a case for that, and if the shift regsiter is True, writes it to the file. Stop logging case will close the file and put a False on the shift regsiter. A stop program state would also close the file and put a false on the shift register, but also wire a True to the stop terminal of the consumer while loop.
Now your code will always have a valid reference when it needs it, doesn't have timing issues with respect the producer loop, doesn't require you to set buttons to switch action and have to programmatically reset them back to false.
