Date: Fri, 29 Jun 2001 00:50:30 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "E.B. Dreger" <eddy+public+spam@noc.everquick.net> Cc: Chris Costello <chris@calldei.com>, freebsd-smp@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: libc_r locking... why? Message-ID: <3B3C3346.E5496485@mindspring.com> References: <Pine.LNX.4.20.0106290356480.3220-100000@www.everquick.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"E.B. Dreger" wrote: [ ... wrapped fd using functions in libc_r ... ] > So it's a thunk/kludge not only to enforce "proper" > behavior, but also to prevent the process from blocking > and stalling other threads? This makes sense. It also permits locks on the descriptors, to ensure that one thread does not modify a descriptor out from under another thread while it is "blocked" on some outstanding operation. [ ... ] > The reason that I asked is because I'm writing a program > that uses rfork() in the same manner as the new > rfork_thread(). I couldn't understand the need to wrap > kevent(2), bind(2), or accept(2)... > > In my mind, I was thinking "data integrity", trying to > prevent processes in the same "thread family" from stepping > on one another. Blocking is not a problem; where I can't > use non-blocking calls, I use a worker thread. 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. > I guess that I was looking at man pages and bits of > libc_r code without understanding the pthread implementation. > I knew that it was userland, but I thought that it created > multiple processes... if this is not the case, then I was > apparently comparing apples to mangoes. This is not the case. 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. > 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. 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 locking primitives in the libc_r library do _NOT_ use the "lock" prefix on the "cmpxchg" instruction, which means that multiple processors are not forced to a rendevous, there's no IPI, and the TLB and L1 cache shootdown isn't moderated by the cache MP 1.4 specification cache coherency protocol, and thus the locks it uses are _NOT_ MP safe. 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 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. -- Terry 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?3B3C3346.E5496485>