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

This is a discussion on Re: Parallel multithreading for I/O operation in linux ? - Linux ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

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

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

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

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

    On 12 Jun., 09:48, Noob wrote:
    > 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_...rticles/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).


    Thank you very much Antonius, I will take a look for your examples.

    jurij.

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

    On 12 Jun., 09:48, Noob wrote:
    > 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_...rticles/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).


    Thank you very much Antoninus, I will take a look for your examples.

    jurij.

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

    On 12 Jun., 09:48, Noob wrote:
    > 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_...rticles/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).


    Thank you very much Antoninus. This info is very helpful.

    jurij.

+ Reply to Thread