looking into a puzzle...
Feb. 18th, 2010 11:39 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
I have a circular file array to store incoming data (since they come randomly, and I'm only interested in the last n); for the sake of sanity check, in my unittest, I have added verification of the fact that timestamps are increasing (as if anybody cares on the consumer side, but I was just trying to make sure the code does not produce shit); now what I see: randomly (yes, it is stupid to run System Under Test in a separate thread, but could not figure out how to bypass it) timestamps are out of order, like this:
Kind of interesting problem, is not it? I'll figure out, but it is funny anyway, how could I possibly achieve it, when there's just one producing thread...
So, what was going on. By honest mistake, 200 ms after I launched that data collector, I stop it. (Should not have, in theory.) Then I ask it to give me the data, k readings (k < n). What it does is this: since it think it is not running, it starts a new thread and starts collecting the data (and my process waits - stupid, right? collect the data in one thread, big deal).
But the thread that was supposed to be stopped, it was never stopped, since it was waiting for us to let it breathe a little bit. And when it gets a chance to run it sees that the flag "I am running" is set to true again; so it does not stop, but goes ahead and collects the data too. So these two guys try to do their best to provide data in parallel. Sure they provide more than I expected.
If not for a unittest, I'd never catch that shit. Okay... one piece at a time. Actually, none of these threads should exist.
900, 1000, 1200, 1100, 1300, 1400...
Kind of interesting problem, is not it? I'll figure out, but it is funny anyway, how could I possibly achieve it, when there's just one producing thread...
So, what was going on. By honest mistake, 200 ms after I launched that data collector, I stop it. (Should not have, in theory.) Then I ask it to give me the data, k readings (k < n). What it does is this: since it think it is not running, it starts a new thread and starts collecting the data (and my process waits - stupid, right? collect the data in one thread, big deal).
But the thread that was supposed to be stopped, it was never stopped, since it was waiting for us to let it breathe a little bit. And when it gets a chance to run it sees that the flag "I am running" is set to true again; so it does not stop, but goes ahead and collects the data too. So these two guys try to do their best to provide data in parallel. Sure they provide more than I expected.
If not for a unittest, I'd never catch that shit. Okay... one piece at a time. Actually, none of these threads should exist.