Date: Tue, 5 Jan 1999 18:18:18 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: wes@softweyr.com (Wes =?iso-8859-1?Q?Peters=D4?=?=?iso-8859-1?Q?=40=21=EA?=?) Cc: tlambert@primenet.com, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. Message-ID: <199901051818.LAA08069@usr02.primenet.com> In-Reply-To: <3691B82E.1D4E4B99@softweyr.com> from "Wes =?iso-8859-1?Q?Peters=D4?=?=?iso-8859-1?Q?=40=21=EA?=?" at Jan 4, 99 11:58:54 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. 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". 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. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199901051818.LAA08069>