Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754054AbcDCQMG (ORCPT ); Sun, 3 Apr 2016 12:12:06 -0400 Received: from mail-ob0-f172.google.com ([209.85.214.172]:33437 "EHLO mail-ob0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752276AbcDCQME (ORCPT ); Sun, 3 Apr 2016 12:12:04 -0400 MIME-Version: 1.0 In-Reply-To: References: <20160402095108.894519835@linutronix.de> <20160402110035.753145539@linutronix.de> <57000D4B.5000406@kernel.org> From: Andy Lutomirski Date: Sun, 3 Apr 2016 09:11:43 -0700 Message-ID: Subject: Re: [RFC patch 4/7] futex: Add support for attached futexes To: Thomas Gleixner Cc: Andy Lutomirski , LKML , Sebastian Andrzej Siewior , Darren Hart , Peter Zijlstra , Ingo Molnar , Michael Kerrisk , Davidlohr Bueso , Chris Mason , "Carlos O'Donell" , Torvald Riegel , Eric Dumazet Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1696 Lines: 51 On Sun, Apr 3, 2016 at 8:56 AM, Thomas Gleixner wrote: > On Sun, 3 Apr 2016, Andy Lutomirski wrote: > >> On Sun, Apr 3, 2016 at 2:57 AM, Thomas Gleixner 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