About the 5.10 'threads' scheduler ::revisited

Wiggins has asked for the wisdom of the Perl Monks concerning the following question:

Ref:About the 5.10 'threads' scheduler
The 1st question in that post was answered; but I failed to dig down to the real kernel of knowledge I was looking for.

I am looking for data on the 'threads' paradigm in 5.10:

User-land or kernel threads?
Answer: A Win32 Perspective:

Kernel.

But what about Fedora 9 / Perl 5.10(pthreads) / Intel Core2 Quad processor?

? Does each thread receive an individual process time slice, or are all threads sharing a single process time slice?

? Can threads from the same process be distributed simultaneously onto different processor cores?

? How does thread creation overhead compare with vfork/execl overhead?

I am obviously going through some design quandaries picking an architecture. I am looking for relative capability data in this area.

Comment on About the 5.10 'threads' scheduler ::revisited

Replies are listed 'Best First'.
Re: About the 5.10 'threads' scheduler ::revisited by BrowserUk (Patriarch) on Oct 29, 2008 at 19:38 UTC
Does each thread receive an individual process time slice, or are all threads sharing a single process time slice? Each thread recieves it's own timeslice. Can threads from the same process be distributed simultaneously onto different processor cores? Ambiguously worded, but any thread of a process can (and will without extraordinary measures to prevent it) be scheduled on any available core. And different threads from the same process may be running on different cores concurrently. How does thread creation overhead compare with vfork/execl overhead? It depends. On many things. Threads can have a heavy spawn-point cost because they do their data copying up front. Forks can appear cheaper up front because of COW, but without extreme care even apparently read-only references to COW pages can cause ongoing piecemeal duplication of data which can ultimately add up to a higher overhead. All that said, you're asking the wrong questions. In most cases, the choice as to whether threads or forks are appropriate for a specific application are less about how fast you can spawn another. It really depends upon what your application is doing. Does it need to share data bi-directionally? Does it require a spawn and discard approach or would it be better served with pooling? Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l]

Replies are listed 'Best First'.

Re: About the 5.10 'threads' scheduler ::revisited
by BrowserUk (Patriarch) on Oct 29, 2008 at 19:38 UTC

Does each thread receive an individual process time slice, or are all threads sharing a single process time slice?
Each thread recieves it's own timeslice.
Can threads from the same process be distributed simultaneously onto different processor cores?
Ambiguously worded, but any thread of a process can (and will without extraordinary measures to prevent it) be scheduled on any available core. And different threads from the same process may be running on different cores concurrently.
How does thread creation overhead compare with vfork/execl overhead?
It depends. On many things.
Threads can have a heavy spawn-point cost because they do their data copying up front.
Forks can appear cheaper up front because of COW, but without extreme care even apparently read-only references to COW pages can cause ongoing piecemeal duplication of data which can ultimately add up to a higher overhead.

All that said, you're asking the wrong questions. In most cases, the choice as to whether threads or forks are appropriate for a specific application are less about how fast you can spawn another.

It really depends upon what your application is doing. Does it need to share data bi-directionally? Does it require a spawn and discard approach or would it be better served with pooling?

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

[reply]
[d/l]