cv_wait

[Ian Lepore]

On Fri, 2020-07-03 at 00:52 +0530, Kamal R. Prasad wrote:
> witness threw a panic saying that there is a potential deadlock. I
> dont
> have the exact msg as I changed the algo and lost the console logs.
> the common code has a mtx_lock() and mtx_unlock() to guard against
> race
> conditions.
> i just want to use a synchrnization primitive that will not hold any
> locks
> when calling the common code from the cs.
> so, pl feel free to suggest any alernativves.
> 
> thanks
> -kamal
> 

Maybe an sxlock is what you're looking for.

void function1()
{
  sx_xlock(&sc->cs_lock);
  common_func();
  sx_unlock(&sc->cs_lock);
}

void function2()
{
  sx_xlock(&sc->cs_lock);
  common_func();
  sx_unlock(&sc->cs_lock);
}

That would ensure that only one caller at a time is in the critical
section that calls common_func()  (if it's just common_func() that
needs protecting, I'd put the sx_xlock in there).  But I'm not sure how
that's different than using a standard mutex, unless your common code
was trying to sleep (or use malloc with WAIT_OK).  If using a standard
mutex caused witness to warn about an unbounded sleep while holding a
mutex, then using the sxlock should fix that.

Also, you should look at 'man locking' if you haven't already.

-- Ian

> 
> 
> On Fri, Jul 3, 2020 at 12:37 AM Ian Lepore <ian at freebsd.org> wrote:
> 
> > On Fri, 2020-07-03 at 00:36 +0530, Kamal R. Prasad wrote:
> > > but if i am doing cv_wait() for the first time, should someone be
> > > calling cv_signal for it to proceed?
> > > my algo is something like this in my driver:-
> > > function1()
> > > {
> > > mtx_lock(&sc->sc_mtx);
> > > cv_wait(&sc->sc_cv);
> > > mtx_unlock(&sc->sc_mtx);
> > > ....
> > > critical section
> > > ....
> > > cv_signal(&sc->sc_cv);
> > > }
> > > 
> > > function2()
> > > {
> > > mtx_lock(&sc->sc_mtx);
> > > cv_wait(&sc->sc_cv);
> > > mtx_unlock(&sc->sc_mtx);
> > > ....
> > > critical section
> > > ....
> > > cv_signal(&sc->sc_cv);
> > > }
> > > ---------------------
> > > i want to protect critical section. The critical section calls a
> > > common
> > > piece of code which has some locks. if i put in locks to guard
> > > the
> > > cs, it
> > > triggers a call to witness().
> > > 
> > > Update: i saw an implementation wherein they used a callout to
> > > periodically
> > > send a cv_signal(). i could do that but the pt of this
> > > implementation
> > > is
> > > that cs in either of these functions should not be eecuting at
> > > the
> > > same
> > > time.
> > > 
> > > thanks
> > > -kamal
> > > 
> > 
> > A condition variable doesn't work the way you're trying to use it.
> > 
> > What is the complaint from witness?  What type of locks are used in
> > the
> > common code that causes a complaint?  Are any of these functions
> > involved called from interrupt handlers (that also imposes
> > restrictions
> > on what kind of locking you can do)?
> > 
> > -- Ian
> > 
> > 
> > _______________________________________________
> > freebsd-arm at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > To unsubscribe, send any mail to "
> > freebsd-arm-unsubscribe at freebsd.org"
> >