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(&obj->mutex); > > -------------------------> > > mutex_enter(&global); > > obj = obj_lookup_and_remove(); > > mutex_exit(&global); > > > > mutex_enter(&obj->mutex); > > while (obj->ref > 0) > > cv_wait(&obj->cv, > > &obj->mutex); > > mutex_exit(&obj->mutex); > > kmem_free(obj); > > <------------------------- > > if (dropped_ref) > > cv_signal(&obj->cv); > > > > If the signal was underneath the lock, there wouldn't be a race. > > But the above code is wrong for a more fundamental reason: it's never OK > to access fields of a structure after you've dropped your reference to it. > (And indeed, adding mutex_enter()/mutex_exit() around the cv_signal() > would do nothing to improve the correctness of the above code ;-)
True. I'll accept that my example is actually of a different problem. =] > I assert that from a correctness standpoint, it never matters if you hold > the lock while doing a cv_signal() or cv_broadcast(). I agree that there > may be performance issues, but it would be nice to see some hard data > since (as previously covered) I can see advantages to not holding the lock > as well. True; it seems like a point which can be argued either way. It shouldn't be too hard to collect data with dtrace(1M). Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development
