We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
So... I have a few threads where data is originating, and two where it's being used. I'm reluctant to use producer/consumer because that's sort of implying this classical resource sharing pattern, but it's close to what I have.
What I want to do is make sure that when the source threads stack up mail in a mailbox, that the consumer can determine how old it is. More so, I can make sure it's not too out of date.
I can't be 100% certain when the information will get there, or when its sitting in mail when it'll get used. So let's say I want 100ms "keep alive" or timestamp or an "expired at" time.
There is clearly a way to do with this osGetTickCount, which I'd then have in the struct of the mail that's getting sent to my consumer thread. I could then look at it and figure out if too much time has passed.
Or would it be better for some reason to use a an osTimer? Start it when I make the request for data, and if I haven't received it all by the time the timer expires I know any data I did receive can be tossed out?
Is there a common way to do this?
I don't understand your second idea.
If there isn't any message pending, then you get a timeout (assuming you specified a timeout). So then there are no old messages available to throw away.
And if you instantly get a message, then your timer - that you started just when you requested a message - will not help you to know how long that message had waited in the queue before your consumer finally decided to pick it up.
Storing time in the messages tells the age of the messages.
Storing time in the consumer only tells you how slow the consumer iteration loop is to get ready for the next iteration - or how long it has to wait on an empty mailbox before something finally arrives.
My consumer doesn't care about the actual age of the message, only that in the last 100ms all the messages from all the producers I need to complete this specific task have arrived, they in turn are responsible for keeping themselves updated. So, in this way, starting a timer would work because if everything arrives and the timer hasn't expired I'm good to go.
But I'm probably with you that using the producer to store the tick number when it's created or sent over is probably better.
I'm not sure yet if I need to loop around inside the consumer checking for and marking data as expired yet. I haven't fully flushed this idea out because I wasn't sure if including the current tick when I make/send the data over was the best way to do this.
Have each producer send an event when they have updated their data. And have them first set a time stamp for that data.
Let the consumer set a flag bit for every type of event it receives. When all bits are set - check all time stamps. If any time stamp is too old, clear those bits and back waiting for more events. If you do get a complete set of bits and finds all data to be fresh enough - perform a computation and clear all flags.
If you did find any of the data too old, then you could optionally update a blame counter for that producer. Verify if any blame counters ticks - then those producers aren't fulfilling their maximum 100ms production interval.
The above would then produce one output result per new data for the producer that is slowest (assuming that the producers are actually able to keep their realtime requirements so you don't get stalled by never getting a full set of data without some producer failing you).