Re: [9fans] plan9 go output faults on 9vx with rfork

[David Leimbach <leimy2k@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2893 bytes --]

On Wed, Jan 19, 2011 at 10:59 PM, ron minnich <rminnich@gmail.com> wrote:

> OK, Pavel sent me a nice piece of code that implements cmpswap using a
> gcc trick. I did not want to use the trick for a few reasons, and
> thought to use futex instead, as it seemed appropriate. Weirdly
> enough, I can not find a simple implementation of cmpswap that uses
> futex, though I can find several papers describing how tricky futex
> is, and one Linux person who told me that futex had evolved in ways
> not necessarily to our advantage.
>
> Every time I'm ready to throw in the towel on Plan 9 and just go with
> Linux I hit something like futex and it's back into the fray ... :-)
>

Actually the mutex implementations I've seen with futex use cmpswap.  Also
my understanding of futex is that it's just an API for a portion of what
needs to be done to implement a fast user space mutex. Essentially you have
to examine the value in user space, see that it's what you expect and move
on unblocked.  If the value differs from what is expected, you must block,
and wait.  This is why they're "tricky" :-).

I do not see anything immediately wrong with using the compiler intrinsic
functions that are supported pretty well across GNU, clang, Intel C/C++ and
I think even Microsoft's compilers.  I do think that gcc does not implement
them for i386, or if it does, it does so with a library routine instead of
the compiler just generating the assembly for that architecture's version.

I've run smack into this problem myself just about 8 months ago, and it was
due to Boost being built with a mismatched architecture from some other code
that was built with another.  The result was that since these builtins get
resolved sometimes at link time, and sometimes at compile time, they don't
behave like normal functions, and you get a mess.

You've got to pick one mess, or implement your own multi-architecture
library of cmpswap and like routines :-).


>
> So, I have committed changes to my vx32 repo and Pavel's sieve now
> works on 9vx on a 32-bit linux vmware image. It should also work if
> you build on freebsd. It should also work if you build on 64-bit linux
> but there are no guarantees, since all this relies on some gcc
> builtins.
>
> You can see what I've done if you look at my repo.
>
> BTW, the sieve ran to 17xxx on linux and then I got some kind of
> malloc failure, I'll assume it's another 32-bit gc issue. I'm up to
> 57917 on osx.
>

If your compiler is generating code for -march=i386, you could see some
funny stuff on 32bit platforms.  Better to use -march=i686.  Might not come
up, but it's something to look for.

I really need to try this version of 9vx sometime instead of just thinking
about it :-)

Dave


>
> You're going to need Pavel's mods to go, I suppose. but that's another
> story ...
>
> ron
>
>

[-- Attachment #2: Type: text/html, Size: 3690 bytes --]