Date: Tue, 5 Jan 1999 12:46:08 -0700 From: Nate Williams <nate@mt.sri.com> To: Terry Lambert <tlambert@primenet.com> Cc: wes@softweyr.com (Wes =?iso-8859-1?Q?Peters=D4?=?=?iso-8859-1?Q?=40=21=EA?=?), bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. Message-ID: <199901051946.MAA09199@mt.sri.com> In-Reply-To: <199901051818.LAA08069@usr02.primenet.com> References: <3691B82E.1D4E4B99@softweyr.com> <199901051818.LAA08069@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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 > > 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. I looked up UITron on the WWW, and only got a hit from Sun, and it was lost in the noise. I have a hard time seeing this as 'Industry Standard', but I'm sure you'll feel free to explain to me how it's a standard. > 2) It's GPL'ed. I'll leave this one... > 3) Object locks are the wrong way to address the reentrancy > issue. Sometime I wonder if you just like to listen to yourself speak. Object locks *ARE* the correct way to address reentrancy issues. Having done *real* multithreaded/multi-object design for some time now, I've found that Object locks are a *much* cleaner way of designing for re-entrant code. (If you don't want something locked, you don't create an object for it...) How much *REAL* (stuff that is used by someone outside yourself) experience do you have designing multi'threaded/whatever' software to speak with such authority? > 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. So you're claiming that the 'Big Giant Lock' is the better way? You can't have it both ways. Nate 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?199901051946.MAA09199>