[lkml]   [2000]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

> 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.093 / U:2.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site