(Warning: rather long message)
> Date: Fri, 29 Jun 2001 00:50:30 -0700
> From: Terry Lambert <[EMAIL PROTECTED]>
>
> [ ... 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 <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>, or you are likely to be blocked.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
