Messages in this thread | | | Date | Sat, 2 Sep 2000 13:08:41 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: thread rant |
| |
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/
| |