On Sat, 2 Sep 2000, Ingo Molnar wrote:
>
> On Fri, 1 Sep 2000, dean gaudet wrote:
>
> > yup you can do this without threads. apache-1.3+mod_ssl for example.
> >
> > but it's not fun, and it's a lot more work on the portability side.
> > inter-process shared memory and inter-process semaphores are
> > notoriously different across platforms... [...]
>
> but it's slower (on SMP) and more error-prone to use threads. We have the
> following task: 'use multiple contexts and share some state'. The 'share
> everything' model overdoes this goal a bit. Why not share the *specific*
> state that should be shared, and nothing more? The fact that this is
> inconsistent across platforms is IMHO not a good excuse - it just shows
> the mistaken concept that threads should be used for such tasks. You are
> right about the semaphore part - i have plans to add a new type of
> semaphore to Linux, which are not as complex as SysV semaphores and are
> not persistent.
i don't understand why another semaphore type is needed -- about the only
semaphore missing is the pshared portion of posix. (recently i ported a
large commercial MTA to linux and the only thing missing was the
pthread_mutexattr_{s,g}etpshare stuff.)
regarding using shared memory/multiprocess -- how do you handle the case
where the shared region needs to grow?
you're the expert here, tell me what i'm missing:
a threaded program growing its memory requires one cross-cpu TLB update in
case other threads are currently running; this requires n-1 messages where
n is the number of CPUs.
a shared memory/multiprocess program needs some sort of note in the shared
mem to indicate another page should be mapped; and as each process
discovers this need for a new mapping it issues a syscall. this requires m
syscalls where m is the number of processes.
if i understand what you're advocating, m will be much greater than n...
does shared mem still work out faster?
i actually think there's far more grossness to trying to figure out when
to grow a shared mem region -- you almost need to check every time you
follow a pointer. and hopefully you can arrange to have the same mapping
in all processes or else you need some sort of extra page table... almost
forced to implement paging in software.
is this really what you mean?
i have no qualms about "sharing as little as possible". i totally agree
with it. i just think "sharing all of memory" is as close to as little as
you can get for some applications. signals, cwd/chroot,
uid/gid/capabilities, this is all crap i don't care about sharing. file
descriptors -- yeesh these are hard, you want some sharing and some not
sharing. (unix fds are one of the really gross places where you can see
that threading was not present in the original unix design.)
other than TLB/page-table changes is there anything else i'm missing which
makes SMP and threading "slow"?
-dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:12 EST