Re: Parallel multithreading for I/O operation in linux ?

[Antoninus Twink]

On 11 Jun 2008 at 19:26, jurij wrote:

Utilizing the multithreading schema, we were awaiting more optimized
time behavior but could not see it. Obviously, during the "reader" is
doing its job, it is blocked; in this time the scheduler could switch
over to "processor" to allow him to process data. In this case we
would have optimized time-behavior.

If you're using user-level threads (e.g. pthreads) and doing synchronous
I/O then it's likely that the whole process is being blocked by the
kernel until the I/O system call returns. To be honest, on a
uniprocessor system you're not likely to get much help from threading in
the situation you describe, even if you do complicated things to get
asynchronous I/O.

[Noob]

Antoninus Twink wrote:

Jurij wrote:

>Utilizing the multi-threading schema, we were awaiting more optimized
time behavior but could not see it. Obviously, during the "reader" is
doing its job, it is blocked; in this time the scheduler could switch
over to "processor" to allow him to process data. In this case we
would have optimized time-behavior.

If you're using user-level threads (e.g. pthreads) and doing synchronous
I/O then it's likely that the whole process is being blocked by the
kernel until the I/O system call returns.

NPTL (which has been the default library for years) is a 1x1 threads
library.

http://en.wikipedia.org/wiki/Native_...Thread_Library
http://www.kegel.com/c10k.html#threads.nptl
http://lwn.net/Articles/10465/

One thread sleeping does not stall the entire process group.

You should have cross-posted to comp.os.linux.development.apps to
give participants a chance to comment.

To be honest, on a uniprocessor system you're not likely to get much
help from threading in the situation you describe, even if you do
complicated things to get asynchronous I/O.

I disagree. His first thread (producer) is pure I/O while his second
thread is pure CPU (consumer).