On Sat, 2 Sep 2000, dean gaudet wrote:
> 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.)
i'd like to have waitqueue based (kernel-space) semaphores such as the
SysV semaphores are, not signal or sched_yield() based ones.
> regarding using shared memory/multiprocess -- how do you handle the
> case where the shared region needs to grow?
i dont understand why this is such an important category. If the sharing
is very high between the threads then it makes sense to use 'shared-all
threads'. But frequently the example given are webservers, which often do
not have alot of cross-request shared state.
> 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.
well, Linux SysV shared memory indeed has a 'software version' of
pagetables, this way if one process faults in a new page (because all
pages are unmapped originally), then the new physical page address can be
discovered by all other subsequent faults in other process contexts. It
works just fine - the thing i dislike about SysV shared memory is not the
VM part but its 'filesystem characteristics' - i think anonymous shared
memory is the way to go.
> file descriptors -- yeesh these are hard, you want some sharing and
> some not sharing. [...]
well (in Linux) you can specify it on a per-filedescriptor level wether to
share or not to share, and you can pass a filedescriptor to another
process and you can establish it there. Is there any API missing in this
area?
> other than TLB/page-table changes is there anything else i'm missing
> which makes SMP and threading "slow"?
it's not slow, it's 'slower' in the 'common memory allocation' case.
Ingo
-
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 : Sat Sep 02 2000 - 07:03:02 EDT