Date: Fri, 3 Oct 1997 23:07:33 -0400 (EDT) From: "Alex.Boisvert" <boia01@castor.GEL.USherb.CA> To: Simon Shapiro <Shimon@i-Connect.Net> Cc: freebsd-dlm@primer.i-connect.net Subject: RE: Don't appologize Message-ID: <Pine.SOL.3.91.971003222649.28737A-100000@castor> In-Reply-To: <XFMail.971003122010.Shimon@i-Connect.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOL.3.91.971003222649.28737A-100000>