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:32:37 -0500 Message-ID: <1112290357.12906.18.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> <1112289765.12906.7.camel@lade.trondhjem.org> 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]:63448 "EHLO pat.uio.no") by vger.kernel.org with ESMTP id S261587AbVCaRcn (ORCPT ); Thu, 31 Mar 2005 12:32:43 -0500 To: Nikita Danilov In-Reply-To: <1112289765.12906.7.camel@lade.trondhjem.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org to den 31.03.2005 Klokka 12:22 (-0500) skreiv Trond Myklebust: > 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. My point is that as far as ordinary tasks are concerned, the lock can acts exactly like a semaphore/mutex would do. As far as asynchronous tasks are concerned, the lock will serialize the execution of the work_struct w.r.t. the ordinary tasks and other work_structs without risk of deadlocking. Cheers, Trond -- Trond Myklebust