Date: 22 Sep 2003 21:11:22 +0100 From: Doug Rabson <dfr@nlsystems.com> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: arch@freebsd.org Subject: Re: kobj multiple inheritance Message-ID: <1064261482.68463.13.camel@herring.nlsystems.com> In-Reply-To: <1423490000.1064260204@aslan.btc.adaptec.com> References: <1064221837.15078.14.camel@herring.nlsystems.com> <1423490000.1064260204@aslan.btc.adaptec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2003-09-22 at 20:50, Justin T. Gibbs wrote: > > I believe that I have the kobj multiple inheritance changes about ready > > for committing now. I have locked up the class handling in kobj and I've > > re-done the method dispatch so that it is MP-safe without needing locks > > (I would appreciate a close look at that part by another pair of eyes). > > I've only just glanced at these patches, but I don't see how the > method cache is now MP safe. Aren't you still vulnerable to a cache > collision from two different threads performing an operation on the > same class? Thats the cunning part :-). The key is that the cache entries now point directly at the method structures instead of being copies of the structure. The main race condition theoretically present in the old code was that one thread could read a cache entry part way through that entry being updated by another thread. Since the cache entries are now simple pointers, that can't happen. The other main change is that kobj_lookup_method will return the method structure pointer as well as updating the cache entry. The caller only uses the pointer returned from kobj_lookup_method - this ensures that the correct method is called even if another thread re-writes the cache entry with a different value, e.g. if two methods hash to the same cache entry. For the more common case of two threads independantly looking up the same method, both will write the exact same value to the cache. > I still believe that the concept of inherited interfaces is better > way to achieve multiple inheritance. The methods I may want to > inherit need not be associated with what we currently call a device > class. The nice thing about your approach is that it doesn't require > a massive rototilling of the drivers, but I fear it doesn't go far > enough toward providing flexible inheritence. It was the mass rototilling which I wanted to avoid. It still seems like a pretty good thing to maintain some kind of API compatibility between FreeBSD 4, 5 and 6 and this method can support that. Your original scheme was 'single inheritance of multiple interfaces'. This patch can support that since you can derive from as many base classes as you like - each base class will be looked at if the previous class doesn't find a match.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1064261482.68463.13.camel>