On Tue, Jul 12, 2005 at 10:20:33PM -0700, Fab Tillier wrote: > > From: Michael S. Tsirkin [mailto:[EMAIL PROTECTED] > > Quoting r. Sean Hefty <[EMAIL PROTECTED]>: > > > > > > I believe that this is purely a userspace issue. I can't see why > > > using a mutex wouldn't work, but I believe that get_event() currently > > > blocks waiting for an event. > > > > > > Note that get_event() may be reporting events associated with an > > > object other than the one being destroyed. > > > > Maybe, create a special kind of event after the object has been destroyed? > > So I think anyway I look at it, the uCM ends up needing to shadow the > CM IDs in user-land to maintain references. If it does that, then Sean's > earlier idea of performing reference counting and blocking destruction > should work fine and maintain the synchronous behavior that exists today.
Correct, this is the way it was done in the gen1 userspace CM. There is a table, protected by a lock, that keeps a reference counted level of indirection between the kernel cm_id and the user visible id. My question is do we really want this, since an application will likely have yet another table containing the app specific connection structure. How that table is locked and managed will differ based on the threading model. I think it's an incorrect assumption that if we create this level thread safety in the uCM then the app connection structure can be placed in a uCM user supplied pointer (e.g. the kCM context variable) and avoid this type of app level connection table. -Libor _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
