[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hurd_condition_wait

From: Neal H. Walfield
Subject: Re: Hurd_condition_wait
Date: 16 Nov 2002 16:01:53 -0500
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2

> This would work assuming I can freely replace __spin_lock and
> __spin_unlock glibc functions by pthread_spin_lock and
> pthread_spin_unlock, and they are compatible.

You can.

> /* Just like pthread_condition_wait, but cancellable.  Returns true if
> cancelled.  */
> int
> hurd_pthread_cond_wait (pthread_cond_t c, pthread_mutex_t m)

I see no reason to rename this function.

Also, this should be:

  hurd_cond_wait (pthread_cond_t *c, pthread_mutex_t *m)

> {
>   /* This function will be called by hurd_thread_cancel while we 
> are blocked in the pthread_cond_wait. We wake up all threads blocked 
> on C,so our thread will wake up and notice the cancellation flag.
> */

Please follow the GNU coding standards.  This is not the only error.

>   else
>     {
>       /* Now unlock the mutex and block until woken.  */
>       pthread_mutex_unlock (m);
>       pthread_cond_wait(c, m);

Wrong.  pthread_mutex_unlock takes a locked mutex.

> I think there is a race condition in this implementation.
> After setting the hook function and unlocking ss->lock, we can receive
> a signal broadcast before we have done a pthread_cond_wait.

That is okay.  Remember, we are just queuing a message so it will be
there when we do the actual wait.

> c) A different implementation using __pthread_enqueue function.

This should be done anyways.

> At the end there is the original hurd_condition_wait function
> attached.

Unless you completely rewrite something, diffs are much more useful.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]