From: Daniel F. <drf...@gm...> - 2007-12-13 21:25:37
|
On Dec 13, 2007 12:35 PM, Nikodemus Siivola <nik...@ra...> wrote: > On Dec 13, 2007 6:49 PM, Daniel Farina <drf...@gm...> wrote: > > Here is a backtrace when running with the new GET-MUTEX. > > > > Unfortunately, it seems everything as one might expect with a naive > > recursive lock. > > This is just too bizarre. I can see three possibilities (aside from > another thread frobbing the mutex back and forth): > > * SBCL has a signal handling bug in the runtime that allows the > thread to be interrupted after it has grabbed mutex. > > But this doesn't explain how it is subsequently released. > > * Your kernel has a signal handling bug causing the above. Same > problem -- doesn't explain what you see as far as I can tell. > > * You have bad memory / processor cache / other magic hardware > bit that causes the thread to see its own write with a small > latency. Quite unlikely, really, but this one actually explains > what is observed... > I think you are not dense, and it is just as bizarre as you think it is. However, pay in mind that it happens systematically on two machines of completely different make but similar architecture. I'm going to try and wrap up the writing of a test case that I can distribute and doesn't have quite so many dependencies so that more data can be gathered. Another alternative is just to throw NOPs after load/stores and see what happens. fdr |