Parallel multithreading for I/O operation in linux ?

[jurij]

At first we should mention that we have a one-processor, linux-machine
(Kernel 2.6.23) and developing an I/O application using g++.

The problem:
we have a task :"reader" which should read sequentially some data from
a device and fill, for example, 4 buffers with it; additionally we
have another task: "processor", its responsibility is to process data
which it can find in these 4 buffers. Our goal is to design this
schema very optimal from the speed point of view.

In case of sequential procedure we would have the following schema:
r-r-r-r p-p-p-p

It means that the "reader", in order to begin next cycle, would wait
during processing until the last of all 4 buffer will be processed.
Then the next cycle should begin, and so on... Each cycle the "reader"
waits for "processor" and wise-versa.

To avoid this sequential schema and to optimize the speed of the whole
procedure we have designed the multithreading schema as follows:

First we start both threads "reader" and "processor". "reader" reads
the first portion of data and fills the buffer. As soon as the first
buffer is filled with data, "processor" will immediately process these
data, at the same time "reader" will read the next portion of data and
fill the next buffer. We thought, we can realize the following
parallel schema:
r-r-r-r
p-p-p-p
in order to reduce time and to increase the speed of the whole cycle.
Our idea to win time in this cycle is based on the possibility to work
in parallel: of CPU and controller of the hardware-device.

After realization of the multithreading we detected, that the time
needed for the cycle remains the same as in case of sequential, non-
multithreading schema.

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.

Question:
Why our multithreading schema described above cannot give us
enhancement in speed?

 

[Ian Collins]

At first we should mention that we have a one-processor, linux-machine
(Kernel 2.6.23) and developing an I/O application using g++.

The problem:
we have a task :"reader" which should read sequentially some data from
a device and fill, for example, 4 buffers with it; additionally we
have another task: "processor", its responsibility is to process data
which it can find in these 4 buffers. Our goal is to design this
schema very optimal from the speed point of view.

This isn't a C++ question and should go to comp.programming.threads.

 

[Gianni Mariani]

jurij wrote:
....

Question:
Why our multithreading schema described above cannot give us
enhancement in speed?

Possible answers:

a) You problem is I/O bound. Meaning that the time it takes to read and
write is far more costly that the processing.

b) You have a bug and you're not processing in parallel.

If you're I/O is interleaved with writes to a single disk drive, then
you also might suffer disk head thrashing. The best way to solve this
problem is to read/write very large chunks (say greater than 20 megs) at
a time. This will force the head to sit relatively still which then
reduces the overall time to perform the operation.

If you can post some of your code, let's see.

BTW - I have an example of this called "hpcopy" which basically copies a
file using large chunks and multithreaded.

http://austria.svn.sourceforge.net/viewvc/austria/src/hpcopy/code/

http://austria.svn.sourceforge.net/viewvc/austria/src/hpcopy/code/hpcopy.cpp?view=markup
http://austria.svn.sourceforge.net/viewvc/austria/src/hpcopy/code/hpcopy.h?view=markup

It's a bit untidy but you should get an idea.

 

[jurij]

jurij wrote:

...


Possible answers:

a) You problem is I/O bound. Meaning that the time it takes to read and
write is far more costly that the processing.

b) You have a bug and you're not processing in parallel.

If you're I/O is interleaved with writes to a single disk drive, then
you also might suffer disk head thrashing. The best way to solve this
problem is to read/write very large chunks (say greater than 20 megs) at
a time. This will force the head to sit relatively still which then
reduces the overall time to perform the operation.

If you can post some of your code, let's see.

BTW - I have an example of this called "hpcopy" which basically copies a
file using large chunks and multithreaded.

http://austria.svn.sourceforge.net/viewvc/austria/src/hpcopy/code/

http://austria.svn.sourceforge.net/...eforge.net/viewvc/austria/src/hpcopy/code/hpc...

It's a bit untidy but you should get an idea.

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

jurij.

 

[Michael DOUBEZ]

Robot a écrit :

Your schema is still sequential.

your 'p's depend on 'r's.

So you should have 4 threads that do 'r' + 'p' in sequence.

No it is not. Re-read the OP question.
It is a classical producer/consumer schema.

The answer is likely to be a bounded I/O or a bug as Gianni Mariani said.

 

[James Kanze]

Robot a écrit :

No it is not. Re-read the OP question.
It is a classical producer/consumer schema.

The answer is likely to be a bounded I/O or a bug as Gianni
Mariani said.

It may also depend on the implementation of threads. Some early
thread implementations in Linux or Solaris, for example, would
suspend the process when a thread waited, even if other threads
had something to do. (This shouldn't be a problem if you have
an up-to-date kernel, and are using pthreads, at least with
these two systems. But you never know.)

 

[Michael DOUBEZ]

James Kanze a écrit :

It may also depend on the implementation of threads. Some early
thread implementations in Linux or Solaris, for example, would
suspend the process when a thread waited, even if other threads
had something to do.

Yes. An alternative in this case could be to use asynchronous io (I
think boost provides an asio lib).

 

[ivailosp]

here some code

#include <SDL/SDL_thread.h>
#include <SDL/SDL.h>
#include <iostream>
using namespace std;

void start(SDL_Thread* tread, int pr_num);
int read(void*);
int process(void* _read);

int main(int argc, char **argv) {
	start(SDL_CreateThread(read, NULL), 3);
	return 0;
}

void start(SDL_Thread* tread, int pr_num) {
	SDL_WaitThread(tread, NULL);
	if (pr_num >= 0) {
		SDL_CreateThread(process, NULL);
		if (pr_num != 0)
			start(SDL_CreateThread(read, NULL), --pr_num);
	}
}

int read(void*) {
	cout << "hi" << endl;
	SDL_Delay(2000);
	return 0;
}

int process(void*) {
	cout << "wow" << endl;
	return 0;
}

SDL supports Linux, Windows, Windows CE, BeOS, MacOS, Mac OS X, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX.

lol