"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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
