From: Vladimir T. <vtz...@gm...> - 2009-09-15 15:38:42
|
On 9/15/09, Sam Steingold <sd...@gn...> wrote: > [3]> (defparameter c (make-thread (lambda () (loop (random 1L3000) (incf > a))))) > C > [4]> (defparameter d (make-thread (lambda () (loop (random 1L3000) (incf > b))))) > ... > %CPU in top fluctuates from 105% to 140% (which is not bad but is not great > either). I would say it is ok - there are too many GC cycles here and heap never grows. > however, (list-threads) hangs clisp in a way that only sigkill (9) helps. > C-c, sigterm have no effect whatsoever, C-z in gdb reveals this: bad. will try to reproduce it. > (gdb) info threa > 4 Thread 0x42463940 (LWP 29518) 0x00002b350ccc5047 in sched_yield () > from /lib64/libc.so.6 > 3 Thread 0x42362940 (LWP 28895) 0x00002b350c9fce74 in __lll_lock_wait () > from /lib64/libpthread.so.0 > 2 Thread 0x42261940 (LWP 25784) 0x00002b350c9fce74 in __lll_lock_wait () > from /lib64/libpthread.so.0 > * 1 Thread 0x2b350cf62160 (LWP 25521) 0x00002b350ccc5047 in sched_yield () > from /lib64/libc.so.6 Why you have 4 threads here? In such cases it is interesting to know where the threads are spinning. Thread 4 above probably spins - but where exactly? I suspect that long floats cause some memory to be overwritten in certain corner cases and this has different behavior on different memory models. I've done following test (i386 linux): realrand.d:114: mant = I_F_float_F(mant,STACK_0); /* convert into float of type of n */ If I return before this call - no crash occurs. If I return after it - crashes happen in few seconds with two concurrent threads. (of course the return value is meaningless - just trying to localize the problem). Vladimir |