Re: [Sbcl-devel] Re: Threads and port to Mac OS X/Darwin Intel

[John P. <jp...@at...>]

Callers of this function are expected to adhere to the semantics as set
out in futex(4).   As  these  semantics  involve  writing  non-portable
assembly instructions, this in turn probably means that most users will
in fact be library authors and not general application developers.

At 07:56 AM 1/21/2006 +0000, Juho Snellman wrote:
><raf...@ma...> wrote:
> > Now for another question. Would it be any easier to bring threads
> > such as intel linux sbcl has to Mac OS X on intel - that is, does
> > having the same underlying hardware platform make porting the
> > existing thread implementation any easier?
>
>It'll be somewhat easier since OS X/Intel would automatically have the
>generational garbage collector, which is a prerequisite for SBCL's
>thread support. The GENCGC would need to be ported to ppc first for
>threads on OS X/ppc (<http://sbcl-internals.cliki.net/GENCGC-ppc>).
>
>It won't be trivial, since OS X doesn't support any locking primitives
>like Linux futexes. The available alternatives (like Posix semaphores)
>aren't very convenient for SBCL's purposes, and would require a fair
>bit of hacking (<http://sbcl-internals.cliki.net/Removing%20futexes>).

(Note: I don't think that the harshness of the following is unwarranted. 
I'd certainly
like to hear the rationale for using futexes, given that no other *nix 
other than the Linux kernel has them.)

from the man page from futex(2):
         Callers of this function are expected to adhere to the semantics 
as set
         out in 
futex(4).   As  these  semantics  involve  writing  non-portable
         assembly instructions, this in turn probably means that most users 
will
         in fact be library authors and not general application developers.

I hope there was a very good payback to use the futex kludge, because 
kludge (not a hack) is the right word for it. A shared memory system sounds 
like it would have been a much better solution than futexes.

Technically, it appears that designing a futex-like system is doable for 
Darwin, given that  with a mach kernel all parts of the system are for all 
intents are user processes, but actually doing it would be another matter. 
It appears the designers still aren't sure why certain behaviors in futexes 
are unexplainable*, how the hell do you code for situations like that?

* FUTEX_REQUEUE (since Linux 2.5.70) ( now that's rather limiting. only 
very recent versions of Linuxes need apply.)

FUTEX_CMP_REQUEUE (since Linux 2.6.7)
There  was  a  race  in  the  intended  use of FUTEX_REQUEUE, so 
FUTEX_CMP_REQUEUE   was   introduced.

And once again the note at the end says:
To  reiterate, bare futexes are not intended as an easy to use abstrac-
tion for end-users. Implementors are expected to be  assembly  literate
and  to have read the sources of the futex userspace library referenced
below.

>--
>Juho Snellman