Re: Hurd_condition_wait

[Neal H. Walfield]

> Is there a race condition before __pthread_block? We can receive
> pthread_broadcast before we have blocked.
> If so, how do we solve that? 

As I said in a previous email, a __pthread_wakeup queues a message on
the waiter's port (using mach_msg).  If this happens before the waiter
calls does a receive on his port (i.e. via __pthread_block calling
mach_msg), then it will be there when the waiter arrives.  If it
happens after the waiter calls mach_msg then the waiter gets the
message.  Thus, no race.

> Would then be necessary a replacement for CPROC_SWITCHING/RUNNING?

We do not use this and I have no reason to believe it is necessary.

> -hurd_condition_wait (condition_t c, mutex_t m)
> +hurd_condition_wait (pthread_cond_t c, pthread_mutex_t m)

You still have not fixed this.

>    void cancel_me (void)
>      {
> -      condition_broadcast (c);
> +      pthread_cond_broadcast (&c);
>      }

If you are going to use __pthread_block and __pthread_wakeup then this
is the wrong approach.  You can just call
__pthread_wakeup (blocked_thread) (but do not use _pthread_self in the
callback as the it may be called from a different thread; the local
variables will of course remain accessible because a closure is
created so just stash the thread structure and use that).
Additionally, do not forget to remove the thread from the wait queue
which, following this approach, you will have to do by hand.


Looking good.  Thanks.