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

List:       dlm-devel
Subject:    Re: [Dlm-devel] New list code and changes to "scheduler" queue
From:       Peter Badovinatz <tabmowzo () yahoo ! com>
Date:       2001-02-23 17:20:16
[Download RAW message or body]

--- Ian D Romanick <idr@cs.pdx.edu> wrote:
<snip>
> > One other point, in clm_getmsg() it calls handle_sync() to deal with a
> message
> > of type MQ_CLM_OUT_MSG (clm_msg.c, 199-202).  We should NEVER have to worry
> > about this.  Back in the mists of time on earlier versions of the lock
> manager
> > under HACMP, they changed aspects of recovery and lock migration (over the
> > course of 3 or 4 major releases, not surprising.)  The MQ_CLM_OUT_MSG
> message
> > was related to dealing with earlier versions of the lock manager running in
> the
> > same cluster.  Since we will not have any of those, this message will never
> > arrive in haDLM_write().  This is discussed sketchily in the comments with
> > clm_sync() (clm_msg.c, 721).
> 
> Ok.  Since you have at least some context on this, I'll leave it to you to
> rip that stuff out.  Just let me know when you're done. :)

Smooth...  very smooth...  ;-)  Won't guarantee today, but I'll get to it.  For
now it should be "mostly harmless."
> 
> > Related to this, a line cond_send_old_sync()(clm_msg.c, 938):
> >     if (clm_low_version() < DLM_FIRST_VERSION)
> > is wrong (yup, I changed it.)  It should be:
> >     if (clm_low_version() >= DLM_FIRST_VERSION)
> 
> Have you checked that in yet?  If not, could you? :)

Just checked it in.
> 
> > Is there a timed sleep on the semaphore, i.e., similar to
> > pthread_cond_timedwait()?  We need the dlmdk thread waking up regularly to
> do
> > the deadlock detection and lock request timeout handling (you're getting
> rid of
> > the cccp kicking, but the others remain.)
> > 
> > Eventually, we should be able to be smarter in setting our timeouts and
> > directly set our semaphore time wait directly to the next due event, rather
> > than all this gorp in timer_tick() and clmdd_task() that repeat checks to
> > ensure they don't get called 'too quickly.'  But, this can wait. 
> 
> I don't know of anything like that.  It should be easy enough to fake it,
> though.  I'd just need to have a repeating timer that kicks the semaphore.
> If the down() returns and the work-queue is empty, then we know that it must
> have been a timer event.  This is similar to the way that things are done in
> CCCP now.
> 
One thing I was thinking of here, modify the timer dependent areas to provide a
call that says when their next event is due, and then set our timed sleep to be
that amount of time, rather than waking every second (or other fixed time) and
doing nothing.  Since all requests (lock api, cccp msgs, etc.) will wake us up,
there is no reason to wake on a short fixed schedule.

   "Schopenhauer was right, don't you think? Life without pain has no
          meaning.  Gentlemen, I wish to give your lives meaning."
                               -- Dr. Hildegaard Lanstrom
                                  Red Dwarf, Season V, "Quarantine"


=====
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!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/

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