Re: [PATCH] futex: add FUTEX_SET_WAIT operation

[Darren Hart]

Michel Lespinasse wrote:
> On Thu, Nov 19, 2009 at 03:13:40PM -0800, Darren Hart wrote:
> > > This is not supposed to require any particular number of CPUs, so I am  
> > > concerned about the hang.
> > >
> > > How reproducible is this for you ? Do you know if the original test code 
> > > I sent hanged in the same way ?
> > I'm basically 2 for 2 on each version of the futex_wait_test. I haven't  
> > seen it run to completion yet. This is on a stock Ubuntu kernel  
> > (2.6.31-15-generic) on my core duo laptop (32 bit).
>
> As we found out in private email conversation before, this was due to hitting
> resource allocation limits while creating the threads. The patch below
> (relative to your set_wait branch) should fix this.
>
> Patch summary:
> * Added FUTEX_WAIT_BITSET/FUTEX_WAKE_BITSET definitions - I do have
>   old enough headers that this was a problem now that you use
>   inline functions in futextest.h

Great, thanks.

> * Changed futex_cmpxchg return type to int - I dont really like this change,
>   but otherwise gcc complains about the volatile keyword being ignored in
>   the returned function type. Feel free to ignore this if you like.

Hrm. Which version of gcc? I've tested with 4.1 and 4.4 with the -Wall 
option, neither complain for me.

> * futex_setwait_lock: changed to a more compact & faster implementation
>   (same algorithm but wrote the loop in a different way)
> * test harness: look at pthread_create return code; if thread creation fails
>   then join with existing threads and exit. Also moved the before/after
>   barrier logic into the test harness rather than the futex_[set]wait_test
>   functions.

I'll split these up and apply - with the exception of the futex_cmpxchg 
bit until we sort out what's going on. It would facilitate patch 
integration in the future if you could break things up functionally and 
use use "git format-patch" to generate the patches.

Again, thank you for the contributions.

--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/