Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753872AbbFOIno (ORCPT ); Mon, 15 Jun 2015 04:43:44 -0400 Received: from smtp2-g21.free.fr ([212.27.42.2]:60411 "EHLO smtp2-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752177AbbFOIng (ORCPT ); Mon, 15 Jun 2015 04:43:36 -0400 Message-ID: <557E9030.6080901@free.fr> Date: Mon, 15 Jun 2015 10:43:28 +0200 From: Mason User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32.1 MIME-Version: 1.0 To: LKML CC: Ingo Molnar , Peter Zijlstra , Thomas Gleixner , Andrew Morton Subject: [Semaphore API] down_interruptible_timeout Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1833 Lines: 59 Hello, The semaphore API provides several flavors of the down primitive: down, down_interruptible, down_killable, down_trylock, down_timeout As far as I can tell, they all call __down_common (except down_trylock, which returns 1 where the others would sleep). I was looking for a version 1) with a timeout 2) that could be interrupted e.g. down_interruptible_timeout, but it doesn't exist. It seems __down_common(sem, TASK_INTERRUPTIBLE, timeout); would work as expected, no? Do you know why it is not offered? (Maybe there is a better way to achieve the same thing?) [POST SCRIPTUM EDIT] I found this 2007 discussion: http://thread.gmane.org/gmane.linux.kernel/498034 At the time, Andrew said "Nobody else has needed to invent new locking infrastructure to do such things and I'd prefer not to do so now." I suppose this is still true :-) [/EDIT] My use-case is pretty simple: A) process-context kernel thread fills a FIFO and calls down(&fifo_empty); B) ISR handles the FIFO-empty interrupt with up(&fifo_empty); However, in case something goes wrong and the interrupt never fires, I don't want the process to be stuck in an uninterruptible sleep. Perhaps I can set a tiny timeout (e.g. 10 ?s) and not worry about the interruptible part for such a small duration? (Hmm, __down_common calls schedule_timeout, which is jiffies-based. I don't think there is a hrtimers flavor. So ?s timeouts would be off the table?) Or I could use the interruptible version, and let the user kill the operation if necessary. I'd like to hear your comments and suggestions. Regards. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/