<br><font size=2 face="sans-serif">Hi Michael,</font>
<br>
<br><font size=2 face="sans-serif">(wow, don't you sleep!)</font>
<br>
<br><font size=2><tt>> I think this will work, too. But I have easier
time reasoning about locks than<br>
> barriers and atomic operations. "bit is protected by priv->lock"
is a simple</tt></font>
<br>
<br><font size=2 face="sans-serif">Correct.</font>
<br>
<br><font size=2 face="sans-serif">Also, some optimization in mcast_send()
could be done by moving the label "out:" </font>
<br><font size=2 face="sans-serif">to just before the spin_unlock() (and
change "mcast = NULL" to "goto out").</font>
<br>
<br><font size=2 face="sans-serif">- KK</font>
<br>
<br><font size=2><tt>"Michael S. Tsirkin" <mst@mellanox.co.il>
wrote on 12/12/2005 04:33:50 PM:<br>
<br>
> Quoting Krishna Kumar2 <krkumar2@in.ibm.com>:<br>
> > stop_thread() <br>
> > { <br>
> >         clear_bit(); <br>
> >         lock();        /*
empty lock/unlock to synchronize with the mcast_send() */ <br>
> >         unlock(); /* make the other routine
FINISH before we start other activity */ <br>
> >         ... <br>
> >         ... <br>
> > } <br>
> > mcast_send() <br>
> > { <br>
> >         lock(); <br>
> >         if (test_bit) <br>
> >         ... <br>
> >         ... <br>
> >         unlock(); <br>
> > } <br>
> <br>
> I think this will work, too. But I have easier time reasoning about
locks than<br>
> barriers and atomic operations. "bit is protected by priv->lock"
is a simple<br>
> rule, and we are not on data path here.<br>
> <br>
> The fact that the race went unnoticed for a while validates this approach<br>
> in my eyes.<br>
> <br>
> -- <br>
> MST<br>
</tt></font>