Steel Bank Common Lisp

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.


-dan

Daniel Barlow wrote:
> 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.
> 
> 
> -dan
> 
After taking a look in the sbcl sources for undocumented juicy bits, I ended up 
using sb-thread:foreground-release as this seems to integrate nicely with the 
sessions handling. I'm not sure about it's exact semantics, though.

John C.

On Tuesday 14 February 2006 14:29, John Connors wrote:
> After taking a look in the sbcl sources for undocumented juicy bits,
> I ended up using sb-thread:foreground-release as this seems to
> integrate nicely with the sessions handling. I'm not sure about it's
> exact semantics, though.
>
> John C.

Not sure whether what you need to do should integrate with session=20
handling, but the low level mechanism session handling employs is=20
condition variables. Have a look at the reader/writer example in the=20
manual if you haven't done so, already.

Cheers, G=E1bor