[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dlm-devel
Subject:    Re: [Dlm-devel] lock strangeness.
From:       Peter Badovinatz <tabmowzo () yahoo ! com>
Date:       2001-06-18 5:43:11
[Download RAW message or body]

--- Ian D Romanick <idr@cs.pdx.edu> wrote:
> > Is it particularly important to the application during a lock request that
> the
> > cluster has lost quorum, as opposed to the lock not being granted since
> it's
> > held by another process?  I can see that in the sense of monitoring the app
> it
> > would be useful, i.e., the app can print 'why' it is blocked on the
> request.
> 
> Ok, let's back up for a second.  At the onset of this discussion, I had
> wondered if there was a way to determine the state of an in-progress lock
> request.  I had used loss of quorum as an example of a reason why an
> uncontended lock might not be granted.  However, I did not expect that the
> DLM would say, "Sorry, no quorum."  I was thinking more along the lines of
> the DLM saying either "work in progress" or "someone else has the lock", and
> that it's it.

Ah, I better see the point.  Ok, if memory serves (and usually it doesn't) then
for asynch requests the answer is not always.  One point is that once the local
DLM knows that it isn't master I think it kicks the result back to the
requestor with the DLM_NORMAL and goes out looking.  Thus we don't yet know if
the lock is held or not, but I think we try to avoid holding the requestor
while we go off and send messages.

In cases where we know the situation without messages (as in your testcase that
prompted this thread), I guess we could return "blocked" but then we may have
some incompatibilities in semantics?  Is it better to ALWAYS return DLM_NORMAL
or to sometimes return NORMAL and sometimes return BLOCKED?

Since such a lock request eventually gets queued (unless NOQUEUE is given) then
through /proc we could always show the status of the request once the DLM has
figured out that it's blocked, and it goes on the queue.  I don't think this is
quite what you meant though.
> 
> Sorry for all the confusion. :)
> 
> > I'm also confused a bit about the reference to blocking the process.
> 
> Yeah.  This is a difference between VMS and Unix at a pretty fundamental
> level.  I think this was just pretty much mentioned for historical reasons.

Thanks, as I said, I was confused ;)
> 
> -- 
> "Government is like a baby. An alimentary canal with a big appetite at one
>  end and no sense of responsibility at the other."
>         -- Ronald Reagan
>                       There is no responsibility at
> http://www.cs.pdx.edu/~idr

Peter


=====
These have been the opinions of:
Peter R. Badovinatz -- (503)578-5530 (TL 775)
wombat@us.ibm.com/tabmowzo@yahoo.com
and in no way should be construed as official opinion of 
IBM, Corp.

__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/

[prev in list] [next in list] [prev in thread] [next in thread]