i have at least 1 thread that process io.
1 thread read data from something to a buffer, other thread write data from this buffer to other port.

can i use file mapping to map these devices (files), and use movs instruction to copy data between 2 devices?

now my problem, i want 1 thread to ReadFile() data into buffer, while in the same time, other thread WriteFile() data to other pipe/file/socket.

how should i do this?

easiest way is read portion of data, and write untill i empty buffer. but this stall reading operation for no reason.

I have been thinking about this problem for some time, and cant find out better solution.
Perhaps something like this:
After each read operation, queue a write operation wich willrepeat untill all data is send.
this scenario suck because i will have to secure socket to exclusive access, and i would have to use rfame to handle offsets.
so i need only 1 writer, wich will remove from its queue write requests.
after each read operation, add to FIFO information about data, like ammount and pointer. writer should remove it with its own speed. when buffer is full, or queue is full, reader should stop adding more. Now what kind of queue it must be, and how i access it? I cant use mutexts, because i cant guarantee that reader and write will be in diffrent threads. I also want to avoid spinlocks, because they are lame, slow, and eat much power = destroy envoronment.
1 variable must be shared in this queue - count. I could use events, but they can be signaled only once, and i would have no way of knowing if writer has finished accessing data, unless i use 2 events - 1 for indication that queue is free to modify, and second - that modification is complete. It create much overhead because events are kernel objects. Were back to simpliest solution, read, and loop with writes.

Do you have a better solution? Should i stick with this?
Of course all operations are overlapped, and i use undefined ammount of threads (1 per logical core for best performance).


is there a way to bypass limit of 64 handles in multi-wait functions?

Why not? You either create threads or you don't. How is there an in-between-state that you can't determine? Do you mean a single core CPU? If so, then mutexes will work just fine with multiple threads.

i use events to queue io completion events.
wich thread respond first - will queue completion event and wait on it. when its signaled, it will jump to my code and do something else, for example read another portion and queue its completion event, or end reading and return waiting.

first i do init stuff with main thread (like allocating heap), then i enumerate cpus, then i create suspended threads for each, then i pass thread handles to each so when 1 die i detect it, i resume them and start waiting on input source, usually pipe, socket, or message. at the end i kill main thread just to keep things simple.


remember i want to take advantage of everything os has to offer (with concern for backward compatibility, win 2000 missing = doesnt exist for me at all).

You don't have to match threads to CPUs. Let the OS work it out.

You did state you "want to take advantage of everything os has to offer" so use it to mange the threads for you, don't go micromanaging something that the OS already has the code for.

You are free to create as many threads as you please, so you can always guarantee a separate thread for read and write (if that is what you want) and then you can use mutexes, or critical sections, or semaphores, or whatever else the OS has to offer.