Re: [Sbcl-devel] [Bug] lost wakeup in condition-wait / condition-notify

[Gábor M. <me...@re...>]

On Thu, Feb 4, 2010 at 11:37 AM, Tobias C. Rittweiler <tc...@fr...> wrote:
> Hi Gabor!
>
> Can you give a short explanation of why there's
>
>  - pthread-futex.c (emulation of futexes 1)
>
>  - pthread-lutex.c (emulation of futexes 2)
>
>  - real use of futexes ?

Historical reasons. We started out with futexes and got spoiled by them.
They are fast, movable in memory and interrupts safe.

Then came another one, called lutex, that was aimed at non-linux platforms.
It was implemented on top of pthreads and requires gc support for moving them.

Then for freebsd pthread-futex was born, I'm not sure what it brought
to the table
in addition to what pthread-lutex did. Anyway, by now I think it's
obsolete as freebsd
now uses umtx that's equivalent to linux's futex.

I have not followed non-linux threads very closely so I may be wrong.

> In particular, why can't we use pthread mutex, and condition variables
> even on Linux? The pthread library seems also be based on futexes and
> heavily optimized. For example, pthread_broadcast does not actually wake
> up all waiters because that would result in heavy contention (and in
> particular cache line bouncing) as all waked up threads try to reaquire
> the mutex.

Yes, but the pthread function are not async signal safe.

> I first thought, doing it ourselves gives us more freedom, in particular
> the deadline stuff. However: Pthreads' mutexes have a trylock, and
> condition-variables a timedwait; so it should be possible to implement
> deadlines on top of the pthread stuff as well. (In fact that's what
> David Rager's patch seems to do.)

I can't see how trylock() helps with deadlines.

> If we could just use pthread directly everywhere, all the glue code
> could hopefully go away, and we could just call the pthread functions
> from Lisp. (Do foreign calls have much overhead?)

I'm not sure how prohibitive that is compared to the stuff we end up doing
anyways in Lisp land. The main problems are interrupt safety, deadlines.

>  -T.
>
> PS. Feel free to reply to this on-list.