[lttng-dev] urcu rfc: privatize urcu/futex.h

[Mathieu Desnoyers]

Hi Lai,

* Lai Jiangshan (laijs at cn.fujitsu.com) wrote:
> futex.h is in urcu/, it means it can be used by users out of the library.
> 
> But
> 
> If the user's system has futex, he should use #include <linux/futex.h>.
> If the user's system don't have futex, it is not good that if the user
> use this compat_futex.
> 
> Because the compat_futex_async()'s behavior is different from the
> futex in linux.  If the caller don't change the value of @uaddr, the
> futex(FUTEX_WAKE) in linux can also wake a thread, but
> compat_futex_async() don't.  (I guess no one use this behavior, but if
> there are someone, we give them a wrong thing)

Hrm, passing a NULL uaddr parameter is really not the targeted use-case.
We could probably just document that uaddr should not be NULL when using
compat_futex ?

> So I suggest urcu/futex.h becomes a private thing for urcu.

Well, if possible, I'd like to keep it public, since it allows us to do
wait/wakeup schemes across many OSes.

Do you have a use-case where you want to wake up all threads, even those
which are not waiting on a specific uaddr ?

> 
> Alternative implements(only describe the alternative FUTEX_WAIT):
> 1) Like compat_futex_noasync(), but use mutex_lock_signal_save() +
> pthread_cond_wait().
> Problem: the thread can't handle the signal when waiting on
> pthread_cond_wait().  (* mutex_lock_signal_save() is implemented in
> compat_arch_x86.c)

The culprit of the problem here is not really on the "wait" side, but
rather on the "wake" side. The wakeup, in urcu, is issued by
rcu_read_unlock() to wake up synchronize_rcu() (if there is one
waiting).

However, we don't want to disable signals and take a mutex each time we
do a rcu_read_unlock, because it would tremendously impact performance.
AFAIK, pthread_cond_signal() is not signal-safe, so it could not be used
without lock+signal save.

Another site where the wait/wakeup is used: in call_rcu, waking up the
worker threads. We also don't want to take a mutex there, to ensure that
call_rcu is wait-free as far as userspace code is concerned.

> 
> 2) Like the linux kernel, use use mutex_lock_signal_save() + hash table
> 	+ sleeping (use poll() + restore signal mask)
> Problem: very complex

Would this solution require a lock+signal save on the wake up site too ?

> 
> Thanks,
> Lai.
> 
> (today I found a old patchset in my private tree, tried to rebase it
> and suddenly notice this urcu/futex.h but the patchset has nothing
> related with urcu/futex.h).

I look forward to see that work!

Thanks!

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com