Date: Fri, 29 Jun 2001 15:19:47 +0000 (GMT) From: "E.B. Dreger" <eddy+public+spam@noc.everquick.net> To: Terry Lambert <tlambert2@mindspring.com> Cc: Chris Costello <chris@calldei.com>, freebsd-smp@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: libc_r locking... why? Message-ID: <Pine.LNX.4.20.0106291334350.7587-100000@www.everquick.net> In-Reply-To: <3B3C3346.E5496485@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
(Warning: rather long message) > Date: Fri, 29 Jun 2001 00:50:30 -0700 > From: Terry Lambert <tlambert2@mindspring.com> > > [ ... wrapped fd using functions in libc_r ... ] [ fd locking, to prevent chopping feet from beneath ] As-needed serialization to prevent breakage = "proper" behavior. I should have been more clear. > The threads scheduler is in user space. It converts a > blobking call into a non-blocking call plus a context > switch. THus blocking _IS_ a problem. Bad wording on my part again; perhaps "a problem that I [think that] I have handled" is better. I'm use nb calls if possible; else I have a long-running worker thread. After my recent question regarding AIO, it looks like it's time to bite the bullet and use that as well. > [ ... thinking that pthreads used multiple processes ... ] > > This is not the case. So I've learned. I'm glad that I didn't use pthreads, then. :-) > The user space threads library does what the original > idea of threads was intended to do, before people started > treating it as the only hammer they had to pound on the > SMP problem with in order to achieve SMP scalability: it > utilizes the full quantum of the process, and minimizes > context switch overhead. Kernel threads don't do either > of these things well, in almost all existing implementations > out there. Agreed on all counts. I'm tempted to continue eschewing the pthread library. I've unrolled code, and store state info in a purpose-specific FSM control block. Maybe I reinvented the wheel, but it wasn't that difficult. > > Am I correct that libc_r does _not_ use multiple processes > > to create threads? > > Yes. All threads run in a single process. The threads > are not intended as a workaround for the SMP scalability > problem. A good thing, IMHO. I was starting to look at libc_r to check my work; I _prefer_ launching multiple processess for SMP scalability, and having an untainted threading model. > Note that you are not going to be able to combine your > rfork approach with this, if your resulting processes > end up running on different CPUs: this is because the Running processes on multiple CPUs is one goal. [ libc_r locks don't assert "lock", not MP-safe ] So the "lock" prefix is the only way to enforce cache coherency? Do you have handy a good reference on IPIs, other than the kernel APIC code (and, of course, Google and NorthernLight searches)? Good to know, but, I'm not using libc_r... I was looking at existing code to help me double-check mine as I go. I'm synchronizing processes with a "giant lock" token that each process cooperatively passes to the next... to simplify: who_has_lock++ ; who_has_lock %= process_count ; Each processes' critical path first checks to see if it holds the token; if so, it performs the tasks that require it, such as locking a finer-grained lock or mutex. It then passes the token, and continues through its critical path. If a thread has nothing to do, I nanosleep(2) to prevent the critical path from degenerating to an extended spin. I'm considering using socketpair(2)s, with a process blocking indefinitely on read(2) until another process write(2)s to awaken it... > If you "need" kernel threads, look at the Linux kernel > threads in the ports collection (it's a kernel module > that builds and installs as a package). You probably > don't, since performance of kernel threads is really only Correct me if I'm wrong, but the only place in my model that really might benefit from kthreads would be the scheduling? i.e., rather than screwing around with nanosleep(2) or socket calls, I could cut the cruft and interact more directly with the scheduler via kthread mechanisms? > about a 20% increment, if you implement them the SVR4 or > Solaris (pre-2.7) or Linux way. It's probably better to > implement with FreeBSD threads as they currently exist, > and get massive SMP scalability when KSE's are brought > into the source tree. KSEs... where can I read up? Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.20.0106291334350.7587-100000>