[mcclim-devel] Threading and Waiting

Daniel Barlow dan at telent.net
Tue Feb 14 11:22:33 UTC 2006

On Tue, Feb 14, 2006 at 09:58:10AM +0000, John Connors wrote:
> While looking for the 'right' way to get a SCBL thread to wait for a 
> specified condition as part of an attempt to update port from the CLOCC, I 
> came across this gem in the McCLIM sources.

Really, there _is_ no 'right' way.  Threads in SBCL (as with threads
in OpenMCL and any other implementation using "native" threads) are
scheduled by the operating system, and the operating system, as a
rule, can't evaluate arbitrary bits of Lisp to decide if a thread is
runnable or not.  So it has to run it to find out if it wants to run
or not, which is not what I or anyone would really consider an
efficient use of resources.

Most of the uses of process-wait in the wild are for implementing
higher-level synchronisation constructs like
mutexes/semaphores/queues, and most of the Lisps with OS-scheduled
threads already have efficient implementations of these that play
nicely with the kernel scheduler (or at least have the potential to,
which a Lisp-based solution will never have[*]).  It would make far
more sense to encourage people to use the higher-level constructs
than provide them with a hacky workaround to shore up shonky code.
See e.g. http://www.cliki.net/BORDEAUX-MP for one possible "standard"
interface that includes mutexes and posix-style condition variables

> Now this will work, but my understanding is when calling sched_yeild, a 
> thread gets completely expired and put at the back of the scheduling queue. 

The semantics of sched_yield have changed (possibly even more than
once) from one Linux version to the next, and I can't even remember
what it's suppsoed to do these days.  I rather suspect that in the
grand scheme of things it doesn't matter too much, as this approach is
never going to be particularly efficient whatever you do.


More information about the mcclim-devel mailing list