This is getting a little off topic, since the original question was about how I can verify that my multithreaded app is robust. But to satisfy your curiosity...
> > There is a case that the computer we're running on is just > too slow so > > the buffer (that our driver fills and our high priority thread > > empties) overflows. We mark the data as incomplete and continue as > > best we can (While recommending that the user get a faster > computer). > > That works ok, but it is a last resort. > > Should the data be processed in real time? IOW, can't you persist the > buffers to a file for later processing if it's going to overflow? Well, in fact, the purpose of the high priority thread is to put the data in a file. In other words, the driver collects data, and puts it in shared memory. The high priority thread pulls it out of shared memory as quick as possible and puts it in a file, or series of files. The first file is opened before any data collection happens, but I can't open all 100 files in advance, so when I see that I've begun writing to the last open file, I start a thread to open the next file. (For complicated reasons, opening a file is time consuming in our case, because we have lots of initialization work to do. In retrospect, we probably shouldn't have done that.) Then a thread processes the data into a more useful form and writes a companion file with important info about the real data. And finally, if there are any CPU cycles left, the user can do all kinds of cool things to the data while all this is happening. In most cases, we can handle everything in plenty of time to do the above in style, but there is always the customer with an old computer and a fast network. The last thing to go is the collecting the raw data to disk. We do have the mechanism to gracefully drop some data, tell the user, and continue on. That all works good, except for the customer who reported a crash that we think was related to switching to the next file. By looking at the code, I found a weak spot and fixed it, but I wasn't sure if that was the problem. We sent the customer the fix and he is now happy, so maybe it was. In any case, I'm not real confident about the fix because we couldn't reproduce the problem here. My original question is whether anyone knew of a way to control threads so that they ran deterministically so we could run tests.
