From: Joel VanderWerf Date: 2002-08-29T13:48:56+09:00 Subject: Re: CompareByValue Dossy wrote: > On 2002.08.29, Ryan King wrote: ... >>Also, I noticed someone added a version that uses a global >>variable to keep track of "seen"s. This version passes all >>tests, but isn't thread-safe... which is a limitation I'd like to >>overcome. We could easily fix it by using thread-specific >>storage, but the more interesting question: How would we devise a >>test that verifies the thread-safety? I suppose we could come up >>with something involving Thread.pass... > > > Create two threads, run a CompareByValue of the same two objects, > one in each thread ... it might require some trickery to expose > the bug (or, multiple test runs, whatnot). Depends on how thread scheduling is done in Ruby. Manually calling #pass introduces a Heisenberg effect, so ideally you would want to keep the original code and somehow randomize thread scheduling. This brings back memories of stress testing an object database engine, using 32 threads on a dual SMP box, running billions of db operations over the course of several days, and then hitting an assertion failure and wondering how the *&%$# you're ever going to be able to recreate it because of the indeterminate scheduling... In Ruby we'd have the advantage of being able to add a pseudo-random element to the thread scheduler, and avoid this nightmare. > Of course, on a single-CPU machine, I'm not sure even this will > work without cooperation of the code-under-test itself ... AFAIK, dual-CPU won't make a difference to Ruby.