Date: Tue, 05 Jan 1999 15:30:40 -0700 From: Wes Peters <wes@softweyr.com> To: Terry Lambert <tlambert@primenet.com> Cc: bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. Message-ID: <36929290.2909A074@softweyr.com> References: <199901051818.LAA08069@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > > > > It's a lot of work, but it's not rocket science. The most > > > complicated piece is the lock manager; to do it right, you need > > > a five dimensional vector relationship (an arc describing the > > > intersection of three two dimensional vectors: the lock list > > > held by a locking entity, the hierarchical list of lockable objects, > > > and the relationship between multiple locking entities within a > > > single process -- threads within a process). > > > > If you wish to see a working example of a microkernel using object > > locks, take a peek at the RTEMS kernel. It's quite portable, and > > supports SMP systems out of the box. See > > > > http://www.oarcorp.com/rtems/rtems.html > > > > for information. > > RTEMS has three unfortunate problems: > > 1) It is not uITRON compliant. There's really no reason to > do an RT system that isn't uITRON compliant. It's the > industry standard, and there is a lot of code (including > embedded browsers) that are available for such systems. Except that out here in the real world uITRON isn't even on the radar screen. I know it's supposed to be big news with the Japanese companies who created it, but the numerous projects being done here in the USA don't even consider it. At all. Ever. > 2) It's GPL'ed. That means that the source code can't be > used to prepare derivative works that have any strategic > value of any kind. I'm really surprised that it was > possible to GPL something supported by a DARPA grant, > given the governments technology transfer requirements > for such grants, but there it is. The problem here is > that embedded OS's are peculiar in that ROM'ing a browser > at the same time you ROM a GPL'ed OS is a little more > than "mere agregation". If you read the RTEMS license page, it is GPL'ed with an exception, and that exception allows you to create and distribute your product, linked with RTEMS, without restraint. In effect, they're using the LGPL with no source distribution clause. The original RTEMS license was much more Berkeley like, but they found a couple of "clients" who were not contributing fixes back and it sorta ticked them off, so they went with this instead. Go figure. > 3) Object locks are the wrong way to address the reentrancy > issue. The problem with object locks is that it puts > objects that don't really need to be in a contention > domain into one in order to satisfy contention in what > are usually very small critical sections having to do > with list manipulation of pointers to the object. This > type of thinking is why most Intel based SMP OS's claim > that scaling past 4 processors is "useless". What they > really mean is that their SMP OS is useless for more > than 4 processors. Yeah, you have to have *some* object > locks for non-reentrant objects (e.g., the I/O bus), but > this is pretty much limited to physical hardware limits, > and isn't really applicable for, for instance, vnodes. Whether this is a problem or not depends on your system architecture. In embedded systems, where the interactions between parts of the architecture are generally both simpler and more limited than in a large, general- purpose computer, contention on the critical objects often is not much of a consideration, because the various system objects have such limited interactions. This is also true of, for instance, I/O processors communicating with a main system processor. RTEMS remains a good example of a working object-locking system that can scale quite easily to a moderate number of processors. -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36929290.2909A074>