cv_wait

[Kamal R. Prasad]

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



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"
>