From owner-freebsd-questions Fri Oct 3 23:35:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA01006 for questions-outgoing; Fri, 3 Oct 1997 23:35:38 -0700 (PDT) Received: from primer.i-connect.net (primer.i-Connect.Net [206.190.143.13]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id UAA29119 for ; Fri, 3 Oct 1997 20:07:40 -0700 (PDT) Received: (qmail 437 invoked by uid 1008); 4 Oct 1997 03:08:09 -0000 Mailing-List: contact freebsd-dlm-help@primer.i-connect.net; run by ezmlm Delivered-To: mailing list freebsd-dlm@primer.i-connect.net Received: (qmail 431 invoked from network); 4 Oct 1997 03:08:08 -0000 Received: from zeus.gel.usherb.ca (132.210.70.7) by primer.i-connect.net with SMTP; 4 Oct 1997 03:08:08 -0000 Received: from castor.gel.usherb.ca by zeus.gel.usherb.ca (4.1/SMI-4.1) id AA05406; Fri, 3 Oct 97 23:07:35 EDT Received: by castor.gel.usherb.ca (SMI-8.6/SMI-SVR4) id XAA29616; Fri, 3 Oct 1997 23:07:34 -0400 Date: Fri, 3 Oct 1997 23:07:33 -0400 (EDT) From: "Alex.Boisvert" To: Simon Shapiro Cc: freebsd-dlm@primer.i-connect.net Subject: RE: Don't appologize In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 3 Oct 1997, Simon Shapiro wrote: > > Hi "Alex.Boisvert"; On 03-Oct-97 you wrote: > [talking about leased locks...] > > I would like to add this functionality. We need to discuss this a bit; > Since the locks are cumulative, how do we date a lock? > Say, we > > #define READ_LOCK 1 > #define CONTROL_LOCK (1 << 1) > > #define READ_CONFLICT (1 << 1) > ... > > What we say is that READ operations only conflict with CONTROL operations. > This allows multiple clients to apply for a read lock. What will happen is > that state_ref_count will increment with every request. > > How do we define the lock's age? From creation time? From the last > request? I really do not have an opinion :-) Well the more I think about this, the more I realize that leased locks can't be enforced by the dlm. We must keep in mind that the whole locking mechanism is "cooperative", the processes are voluntarily using this concurrency mechanism (the resources themselves are never physically unavailable, so if a process really wanted to access a resource, it could at any time). If we had leased locks in the dlm, the dlm would have to inform the lock owner that one/many locks have expired. This isn't very practical since it's an asynchronous event sent from the kernel to kernel/userspace. Also, it would involve very sensitive time synchronizations between local and remote hosts. From what I read on this subject, this ain't pretty. I think the right way is to have the lock owner willingly enforce the lease time by themselves. This way, the dlm stays simple & elegant and only the dlm clients that want leased locking are penalized by the added complexity (and there is no asynchronous events ("push") between the dlm and its clients). A client that receives a lock can place it's own timestamp on it and release it when an arbitrary time as passed. This is in line with the spirit of "cooperative" concurrency. So next time I'll ask about a new feature, I'll think about its implications first ;-)