Date: Tue, 03 Jul 2001 03:17:12 -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: <3B419BA8.3D93EB5A@mindspring.com> References: <Pine.LNX.4.20.0106291334350.7587-100000@www.everquick.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"E.B. Dreger" wrote: > [ 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)? See other posting. > 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 ; Your unsimplified assembly is not happy, and neither is this. You want to use a LOCK CMPXCHG to implement your mutexes; the LOCK prefix makes it a barrier instruction, which is needed to ensure that two processors don't operate on their L1 cache contents, and then both attempt to write back, where one wins the race, but both think they own the lock. > 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. You aren't going to be able to safely hand this off if they are running on two different processors in user space. You _must_ implement an MP safe mutex. > 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... This would work, but it will destroy your SMP scaling that you want to achieve, since you will effectively serialize your processes running. > > 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? Not really. That's the problem with Linux threads: you don't get thread-group affinity, so if you are running anything on your system besides your threaded application, you tend to take full heavy-weight context switches. Some work was done on the Linux scheduler to try and get this affinity, but you really can't do that sanely in the scheduler: it's the wrong place to attack the problem. The planned FreeBSD approach can fix this, if it's implemented correctly, since as long as you have user space threads that are ready to run, you will run out your entire quantum, and do light weight switches from one thread to another within the same process. > > 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? http://people.freebsd.org/~jasone/kse/ -- Terry 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?3B419BA8.3D93EB5A>