This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: wait for CLONE_THREAD
2009/7/22 ? しん <navy.xliu@gmail.com>:
> thanks for response. i think i really need a specialized thread lib. before
> that, i conducted an experiment to measure the cost of thread. both plain
> pthread way and thread pool.
> because our programs follow a fixed pattern of multi-thread: a group of
> computation-intensive tasks will be fired in burst. and then main program
> uses barrier to synchronize them.
> thread pool uses conditional variables to control tasks. a task costs about
> 10us and has problem of scalability. we expect to reduce thread cost and
> scale well for SMP.
What thread cost? The cost to create a thread? Why are you creating
and destroying threads? Just keep the pthread threads running, and use
shared memory or conditional variables to signal them to do more work.
> in addition, we don't worry about portability because this is researching
> attempt. the primary task is to obtain maximal Gflops on 8 core SMP system(
> core 2 duo, Linux)
>
> i would like to implement thread model describing as follows:
> http://code.google.com/p/libvina/source/browse/libSPMD/DESIGN
That sounds like a very interesting problem!
However, remember the gold rule "Don't optimize prematurely."
I suggest you ignore writing your own thread library for now, work on
a pthread implementation and show a proof of concept *before*
optimizing.
If you want to ignore this advice then you need to construct a test
case to show your problem and post the test case to libc-help.
Please note that your problem is not a C library problem, but rather a
kernel syscall programming problem, but I will admit that the glibc
community has the most experience programming using kernel syscalls.
Cheers,
Carlos.