Re: [RFC patch 4/7] futex: Add support for attached futexes

[Andy Lutomirski]

On Sun, Apr 3, 2016 at 8:56 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> On Sun, 3 Apr 2016, Andy Lutomirski wrote:
>
>> On Sun, Apr 3, 2016 at 2:57 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>> > On Sat, 2 Apr 2016, Andy Lutomirski wrote:
>> >
>> >> On 04/02/2016 04:09 AM, Thomas Gleixner wrote:
>> >> [omitted due to some Thunderbird bug, sigh]
>> >>
>> >> What happens if you mix attached an non-attached ops on the same futex?
>> >
>> > Not much. You might get an error code, sleep forever or the call will just
>> > result in a NOP wasting cpu cycles. That's the same when you mix
>> > shared/private operations on the same futex.
>>
>> What's the workflow?
>>
>> Can the creation of an attached futex fail due to memory allocation
>> problems or any other reason?  If so, how does a library make sure it
>> falls back to a normal futex safely?
>
> Well, other operations on futexes can fail as well and the library or the
> usage site has to take care of it. It's not that different.
>
>> Why can't private futexes be attached by default?
>
> We _can_ attach any futex - private or not - by default.

Then I feel like I'm missing something.  Why does this need an API
change?  Why can't the kernel just attach all futexes?

The reason I'm asking about failures is this:

int some_futex;

Thread 1:
   attach some_futex;
   ...
   wait for some_futex;

Thread 2:
   attach some_futex;
   ...
   wake some_futex;

If one but not both of the attach operations fails and the other
doesn't, then either the thread that failed to attach can't operate on
the futex or, if it tries to fall back to a normal futex, then the
wake won't wake the waiter, right?  This seems fragile.

--Andy