> You are correct. The notion that the mutex needs to be held across
> calls to cv_signal() or cv_broadcast() is simply false. It might
> have been true with very early implementations of the cv code for
> some reason, but it's certainly not true today.
I've filed 6437070 to correct the man
> Of course; I think my example still stands, though. For example:
>
> int dropped_ref = 0;
>
> mutex_enter(&obj->mutex);
> if (--obj->ref == 0)
> dropped_ref = 1;
> mutex_exit(&obj->mutex);
> ->
>
> I agree that the argument in cond_signal(3C) is bogus
So it seems a manpage CR is in order. However, it disturbs me that such
wording ever found its way into our documentation.
--
meem
> ... but that rationale looks bogus to me. In particular, the thread
> heading into cond_wait() must have already tested the condition under the
> lock and concluded it was false in order to decide to cond_wait(). Since
> any thread changing state that would affect the condition must also be
> h
On Fri, 2006-06-09 at 15:52, Jonathan Adams wrote:
> If I remember correctly, the main problems you can run into with signaling
> after dropping the lock is that there can be destruction races:
>
> thread 1Thread 2
>
> mutex_exit(&obj->mutex)
>
> Whether this is good or bad, this is the official requirement. A quote from
> the condvar(9F):
>
> cv_signal() signals the condition and wakes one blocked
> thread. All blocked threads can be unblocked by calling
> cv_broadcast(). You must acquire the mutex
On Fri, Jun 09, 2006 at 05:38:33PM -0400, Peter Memishian wrote:
>
> > Of course; I think my example still stands, though. For example:
> >
> >int dropped_ref = 0;
> >
> >mutex_enter(&obj->mutex);
> >if (--obj->ref == 0)
> >dropped_ref = 1;
> >mutex_exit(&ob
On Fri, Jun 09, 2006 at 05:21:51PM -0400, Peter Memishian wrote:
>
> > I agree that the argument in cond_signal(3C) is bogus
>
> So it seems a manpage CR is in order. However, it disturbs me that such
> wording ever found its way into our documentation.
Indeed; it looks like it's been there s
On Fri, Jun 09, 2006 at 04:16:08PM -0400, Bill Sommerfeld wrote:
> On Fri, 2006-06-09 at 15:52, Jonathan Adams wrote:
>
> > If I remember correctly, the main problems you can run into with signaling
> > after dropping the lock is that there can be destruction races:
> >
> > thread 1
On Fri, Jun 09, 2006 at 03:24:00PM -0400, Peter Memishian wrote:
>
> > Whether this is good or bad, this is the official requirement. A quote
> from
> > the condvar(9F):
> >
> > cv_signal() signals the condition and wakes one blocked
> > thread. All blocked threads can
>
> > IIRC the main reason for this was to avoid priority inversion -- if you
> > drop the lock and get preempted by a higher-priority thread before you
> > can cv_signal(), the cv_signal won't happen for a while and so a
> > higher-priority thread in cv_wait() might not get to run for a while
> IIRC the main reason for this was to avoid priority inversion -- if you
> drop the lock and get preempted by a higher-priority thread before you
> can cv_signal(), the cv_signal won't happen for a while and so a
> higher-priority thread in cv_wait() might not get to run for a while.
OTOH, i
On Thu, 2006-06-08 at 06:48, Roch wrote:
> Quick background check: Is the thread calling cv_signal()
> holding the lock passed to cv_wait ? Normally it should.
So, for what it's worth, I've seen a lot of people confused about why
this is necessary or even helpful.
IIRC the main reason for this wa
On Tue, Jun 06, 2006 at 07:37:27PM -0700, Pavan Reddy wrote:
> Hi All,
> I am trying to debug a conditional variable at this situation:
>
> I have a daemon running and I am trying to send a signal to it thru
> cv_signal()
> controlled by a conditional variable. The first request I sent to it
Quick background check: Is the thread calling cv_signal()
holding the lock passed to cv_wait ? Normally it should.
-r
>
> Hi All,
> I am trying to debug a conditional variable at this situation:
> I have a daemon running and I am trying to send a signal to it thru cv_signal
> controlled by a conditional variable. The first request I sent to it works
> fine and when it comes to the second request, I am not abl
Yes it is.
Roch wrote:
>Quick background check: Is the thread calling cv_signal()
>holding the lock passed to cv_wait ? Normally it should.
>
>
>-r
>
>
>
Hi All,
I am trying to debug a conditional variable at this situation:
I have a daemon running and I am trying to send a signal to it thru cv_signal()
controlled by a conditional variable. The first request I sent to it works fine
and when it comes to the second request, I am not able to wake
18 matches
Mail list logo
