Hi Michael,

(wow, don't you sleep!)

> I think this will work, too. But I have easier time reasoning about locks than
> barriers and atomic operations. "bit is protected by priv->lock" is a simple


Correct.

Also, some optimization in mcast_send() could be done by moving the label "out:"
to just before the spin_unlock() (and change "mcast = NULL" to "goto out").

- KK

"Michael S. Tsirkin" <[EMAIL PROTECTED]> wrote on 12/12/2005 04:33:50 PM:

> Quoting Krishna Kumar2 <[EMAIL PROTECTED]>:
> > stop_thread()
> > {
> >         clear_bit();
> >         lock();        /* empty lock/unlock to synchronize with the mcast_send() */
> >         unlock(); /* make the other routine FINISH before we start other activity */
> >         ...
> >         ...
> > }
> > mcast_send()
> > {
> >         lock();
> >         if (test_bit)
> >         ...
> >         ...
> >         unlock();
> > }
>
> I think this will work, too. But I have easier time reasoning about locks than
> barriers and atomic operations. "bit is protected by priv->lock" is a simple
> rule, and we are not on data path here.
>
> The fact that the race went unnoticed for a while validates this approach
> in my eyes.
>
> --
> MST
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Reply via email to