gb at clozure.com
Tue Jun 3 01:26:57 UTC 2008
Enclosed is an equally stupid C version of the same code. To compile
shell> cc -o stupid stupid stupid.c -lpthread
and to run it:
If you're lucky, you'll be able to interrupt it via ^C at the point
where things become intolerable but before they become hopeless. If
you're unlucky, you may need to reboot (so don't try this unless you're
prepared to do that.)
I'm sure that with a little thought we can convince ourselves that
trying to schedule N compute-bound threads on M CPUs can't work too
well if N is significantly greater than M. Long before any other
resources get exhausted, the likelyhood of any thread in the system
getting scheduled and getting enough of a time slice to do anything
useful becomes very small. In both Peter's example and the C example
above, the factor that keeps the OS from running out of resources
(memory for stacks, kernel and other resources) before the system
becomes totally unusable is the fact that the thread that's sitting
in a loop creating other threads doesn't get much CPU time: the
time it takes to create a thread increases (and the rate at which
threads can be created therefore decreases) pretty dramatically
and pretty quickly.
If anyone thinks that compute-bound threads don't compete with
each other for CPU time, Peter's example is a convincing demonstration
to the contrary; if anyone thinks that this has much to do with CCL
or lisp, I hope that my example will be equally dissuasive.
Since I'd be surprised if too many people believe that, I'm not
sure what other value either example has.
On Mon, 2 Jun 2008, p2.edoc at googlemail.com wrote:
> This repeatedly freezes the whole machine (a G5 quad), needing a power reboot.
> Welcome to Clozure Common Lisp Version 1.2-r9226-RC1 (DarwinPPC32)!
> ? (defun stress-test ()
> (loop for n from 1 do
> (process-run-function (format nil "Stress ~D" n)
> #'(lambda () (loop do (1+ 1))))))
> ? (stress-test)
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 443 bytes
More information about the Openmcl-devel