Date: Fri, 20 Oct 1995 12:22:12 -0700 (PDT) From: Julian Elischer <julian@ref.tfs.com> To: rminnich@Sarnoff.COM (Ron G. Minnich) Cc: cimaxp1!jb@werple.net.au, mira!sdsp.mc.xerox.com!leisner@werple.net.au, hackers@freebsd.org, jb@cimlogic.com.au Subject: Re: NetBSD/FreeBSD (pthreads) Message-ID: <199510201922.MAA00242@ref.tfs.com> In-Reply-To: <Pine.SUN.3.91.951020090350.852A-100000@terra> from "Ron G. Minnich" at Oct 20, 95 09:10:43 am
next in thread | previous in thread | raw e-mail | index | archive | help
Actually I believe I still have the code 'pack-rat'ed away somewhere.. I'd like to be able to add it to the FreeBSD kernel, and I'm not alone, but it's such a deep-seated set of changes that I think it deserves more of a analysis than I have been able to give it. When Davidg comes out of 2.1 coma, and maybe john dyson is available I'd like to go over this stuff for a couple of itterations to get it to the stage that everyone is happy with it and put it into the kernel.. certainly a 'threads' implimentation based on rfork is a very tempting way to go. have you kept your code -up-to-date? when I saw it last, it was a NETBSD implimentation and I didn't have the time top port it.... there are a couple of things I'd like to see before I pulled it into -current: 1/ Able to be COMPLETELY left out if so desired.. i.e. not configuring it in should leave every thing EXACTLY as it is now 2/ supplied as a set of patches to -current 3/ agreement from davind and john 4/ documantation and possibly references to the original idea (plan9?) For the record, Kirk said at the 4.4 course I did a while ago that he thought that rfork was a good alternative to kernel threads.. do you have a pointer to your present code? > > I implemented a simple version of plan9 rfork() a little while ago (well, > a year ago). You could rfork and end up with shared data space and file > table. I also implemented a very simple lock/unlock primitive that was > far more efficient than system v semaphores, since in the common case > (no contention for a lock) there's no jump to the kernel to wake up > other procs when you acquire or free a lock. Between these two things you > can do a lot: share data, share locked structures, share open files, etc. > I can do all of what i commonly do with kernel threads on, e.g., Irix. In > fact I implemented a simple user-space distributed shared memory with > these basic parts: on sgi's i used their kernel threads/kernel mutex > code, on freebsd i used rfork/lock code i built. > > For my money this is about as good as kernel threads. There's not the > additional complexity in the kernel (have you ever seen what LWP did to > sunos? No? good.). > > This code has been available gratis for a year. I can't convince anyone > to pull it into core for netbsd or freebsd, but I'll make the offer > again: you want it, let me know. The code, btw, is less than 100 lines > for each change. In fact the fastlock code is something like 25 lines. > I've implemented them as LKMs and directly as part of the kernel. > > ron > > Ron Minnich |Like a knife through Daddy's heart: > rminnich@earth.sarnoff.com |"Don't make fun of Windows, daddy! It takes care > (609)-734-3120 | of all my files and it's reliable and I like it". > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510201922.MAA00242>