From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: [RFC] Add support for semaphore-like structure with support for asynchronous I/O Date: Thu, 31 Mar 2005 12:22:45 -0500 Message-ID: <1112289765.12906.7.camel@lade.trondhjem.org> References: <1112219491.10771.18.camel@lade.trondhjem.org> <16971.44683.69638.768508@gargle.gargle.HOWL> <1112272290.10975.71.camel@lade.trondhjem.org> <16972.11959.741426.960922@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Linux Filesystem Development Return-path: Received: from pat.uio.no ([129.240.130.16]:10179 "EHLO pat.uio.no") by vger.kernel.org with ESMTP id S261582AbVCaRWz (ORCPT ); Thu, 31 Mar 2005 12:22:55 -0500 To: Nikita Danilov In-Reply-To: <16972.11959.741426.960922@gargle.gargle.HOWL> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org to den 31.03.2005 Klokka 21:09 (+0400) skreiv Nikita Danilov: > > You are assuming that all the waiters on the queue are tasks that must > > sleep if they cannot take the lock. That is not the case here. Whereas > > some users will indeed fall in this category, I expect that most will > > rather want to use the non-blocking mode in which the caller is free to > > go off and do other useful work. > > Ah, I see... But this doesn't look like semaphore _at_ _all_. Semaphores > have no call-backs, and in iosem case it's callback (in the form of > struct work_struct) that is central to the interface. I belive naming should > reflect this, it's utterly confusing as it is. Maybe struct > work_queue_token and schedule_work_{with,end}_token()? That would be equally confusing. The lock exists to serialize _BOTH_ tasks and work queue items. For instance the NFSv4 OPEN takes the token synchronously, and it needs to be serialized w.r.t. the asynchronous CLOSE or OPEN_DOWNGRADE. Cheers, Trond -- Trond Myklebust