Date: Thu, 02 Jul 2020 13:45:12 -0600 From: Ian Lepore <ian@freebsd.org> To: kamalp@acm.org Cc: freebsd-arm@freebsd.org Subject: Re: cv_wait Message-ID: <f3b1ae0198d83294b46a2b93b085ad75509e8bcd.camel@freebsd.org> In-Reply-To: <CAK=yUG%2BA3n-dSHg0w1mJ141njwb4uE=oeUTab6pCMRM924Dhjw@mail.gmail.com> References: <CAK=yUGLoM1YWX5yxsboKqaCMr2jKGgtJ0a-CVVsfeEO3SpsYLQ@mail.gmail.com> <ef01153a05887b10a443c71cb42aff6180ae7f8f.camel@freebsd.org> <CAK=yUGLvZ7uM=pTNrODnTgw6NStT4gHExsTDkrYTP_rQBV1C-A@mail.gmail.com> <28698f3e3db608dceee910a8ba62ad7b6be0769f.camel@freebsd.org> <CAK=yUG%2BA3n-dSHg0w1mJ141njwb4uE=oeUTab6pCMRM924Dhjw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > To unsubscribe, send any mail to "
> > freebsd-arm-unsubscribe@freebsd.org"
> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f3b1ae0198d83294b46a2b93b085ad75509e8bcd.camel>