Wednesday, March 14, 2012, 9:29:43 PM, John Plevyak wrote: > My view is that this is only one of many failure modes, albeit the most > common one.
I disagree because only in the close case is the lock itself de-allocated. In all other cases the locks continue to be valid. So while all the other modes can be synchronized via locks, closing the NetVC cannot be. Before I started making fixes the crashes were almost all at the point of accessing the lock, not the NetVC itself. > If the locking was working, then the client would clear all > pointers to the netvc I am still failing to see how, in my example timeline, the client in thread A can cause the client in thread B to drop its NetVC pointer, or even detect the fact that there is a pointer in thread B. Even if the operations are completely temporally disjoint (the point of locking) it will crash when thread B accesses the invalid lock or NetVC. No simultaneous access is required in the example scenario. The entire point of the reference counting in the patch is to provide that detection mechanism, so that thread A can in fact wait for the thread B client to drop its pointers. I don't see how that can be done with only locks if the locks themselves can become dangling pointers.
