Thread Pool really improves performance for Current OS ? -C language.

[Sheth Raxit]

hi,

one query, in modern OS (OS come after 2000) (and relavant library)
(mainly POSIX-Thread) normally which are doing user level threading,
not kernel level (having Multiple Physical CPUs)

I recently come to know about some article (SEDA)
(www.eecs.harvard.edu/~mdw/proj/seda/ )
which are doing AsyncIO+Multithreading+EventDriver Stuff, and it
performs poorly on C-Code and performs Well on Java.

1.
Will ThreadPool (or SEDA ) will really improve performance compare
to Threaded Concurrent Server (using pthread) ? (Also assume
programming language is C / Not JAVA)

2. Any Guideline on when to use SEDA like architecutre?

3. any opensource library/framework (compatible to pthread - or if not
required minimum change) to use with C (for threadpool) or for SEDA-
equivalent ?

4. Is this really can utilize multiple physical CPU ? (like imatix
kernel can't schedule thread on multiple cpu)
(plz assume its for C language, *nix OS )

--Raxit

[Dave Butenhof]

Sheth Raxit wrote:
> hi,
>
> one query, in modern OS (OS come after 2000) (and relavant library)
> (mainly POSIX-Thread) normally which are doing user level threading,
> not kernel level (having Multiple Physical CPUs)

Although SOME POSIX implementations do user-level scheduling, ALL major
implementations do kernel-level scheduling across cores. Nobody does
ONLY user-level scheduling. (And any weird implementation you might find
that does should be aggressively shunned. ;-) )

> I recently come to know about some article (SEDA)
> (www.eecs.harvard.edu/~mdw/proj/seda/ )
> which are doing AsyncIO+Multithreading+EventDriver Stuff, and it
> performs poorly on C-Code and performs Well on Java.

I haven't read it, but I wouldn't put much stock on claims like that.
Java and C are both language runtimes. If they're comparing the two on
the same OS and hardware, then if they behave differently its due to
artifacts in the software stack. If they haven't identified the reasons
for these artifacts, it's either because they didn't bother or couldn't
figure out how. While it's hard to affect many artifacts of the broad
and deep Java VM stack, it'd be easy to affect most aspects of the
relatively shallow C software stack -- if you understood the reasons for
the artifacts.

> 1.
> Will ThreadPool (or SEDA ) will really improve performance compare
> to Threaded Concurrent Server (using pthread) ? (Also assume
> programming language is C / Not JAVA)

Absolutely. And not at all. It depends entirely on your application, and
how you USE the techniques or libraries within the application. These,
like many others, can help you to design effective applications, if used
correctly and appropriately. Used incorrectly, or just inappropriately,
they can help you make an enormous mess of it.

> 2. Any Guideline on when to use SEDA like architecutre?

When the tool suits your needs; and not otherwise. ;-)

> 3. any opensource library/framework (compatible to pthread - or if not
> required minimum change) to use with C (for threadpool) or for SEDA-
> equivalent ?
>
> 4. Is this really can utilize multiple physical CPU ? (like imatix
> kernel can't schedule thread on multiple cpu)
> (plz assume its for C language, *nix OS )

Linux? Solaris? AIX? HP-UX? Windows? Mac OS X? All will schedule your
application threads across available cores, transparently. So will many
others.

[Markus Elfring]

> 3. any opensource library/framework (compatible to pthread - or if not required
> minimum change) to use with C (for threadpool) or for SEDA-equivalent ?

Are any approaches that are referenced by a well-known article appropriate for
your use case?
http://en.wikipedia.org/wiki/Thread_pool_pattern

Regards,
Markus

[Chris Thomasson]

FWIW, here is a high-level diagram I had to create of a simple event
distributor scheme:

http://appcore.home.comcast.net/vzoom/msgsys.pdf

that you can use as the base of a SEDA implementation...