On Wed, Jun 13, 2012 at 4:05 PM, Dawid Weiss <[email protected]> wrote:
> This would require some kind of quantified per thread time > allocation... It would, and would probably have to have control down in the OS and CPU. > and would most likely be ruined by any I/O or some other > kind of external stimuli? I think it could still work, in theory? It'd just mean the other threads must stall if thread X is blocked on IO if in fact thread X was supposed to run before the others. > Interesting idea but I don't think it's > possible to achieve. It certainly wouldn't be easy to do ... but it sure would it be nice :) > There's been some talk about tools to detect data races at the hotspot > mailing list. I forgot the pointer but there is a tool that attempts > to follow all the execution paths and detect potential problems there. > As you can imagine, it doesn't really work on anything but small > examples because the number of states explodes with codebase size. That sounds great too. Or, even, just a way to record and then visualize what the thread scheduling had been for a given test failure. In this case I could have easily seen that a merge had completed before the NRT reader was pulled (which is... unusual). Mike McCandless http://blog.mikemccandless.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
