CreateIoCompletionPort C# equivalent

[Guest]

Hi,

I Wonder... What is the C# CreateIoCompletionPort equivalent? is there a managed IO completion mechanism? can I use 'System.Net.Sockets' in combination with an IOCompletion port?
Any pointers or samples will be appriciated...

Nadav
http://www.ddevel.com

 

[Nicholas Paldino [.NET/C# MVP]]

Nadav,

The BeginSend/EndSend, BeginReceive/EndReceive methods use IO completion
ports for their asynchronous implementation.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi,

I Wonder... What is the C# CreateIoCompletionPort equivalent? is there a

managed IO completion mechanism? can I use 'System.Net.Sockets' in
combination with an IOCompletion port?

 

[Guest]

Thanks for the immediate response, Still, I didn't find any class that provide the SAME functionality as an IO Completion port: using a completion port one may bind several File handles ( e.g. file, socket, stdout, ... ), to a single port, by doing so the system will use a single thread ( or multiple threads, equivalent to the amount of processors ) for all async tasks for the associated handles, this will achieve best performance by decreasing the amount of context-switches done...

Usage of BeginSend/BeginRecieve may ( internally ) use the IO Completion mechanism BUT doesn't enable the usage of a [SINGLE] IO Completion port for several asynchronous tasks, SOooo it doesn't fit the same manner described above... what should I do to achieve the functionality just described using the .NET framework???? any pointers/samples or ideas will be appreciated.

Nadav
http://www.ddevel.com

Nadav,

The BeginSend/EndSend, BeginReceive/EndReceive methods use IO completion
ports for their asynchronous implementation.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi,

I Wonder... What is the C# CreateIoCompletionPort equivalent? is there a

managed IO completion mechanism? can I use 'System.Net.Sockets' in
combination with an IOCompletion port?

Any pointers or samples will be appriciated...

Nadav
http://www.ddevel.com

 

[John Vottero]

Thanks for the immediate response, Still, I didn't find any class that

provide the SAME functionality as an IO

Completion port: using a completion port one may bind several File handles

( e.g. file, socket, stdout, ... ), to a

single port, by doing so the system will use a single thread ( or multiple

threads, equivalent to the amount of

processors ) for all async tasks for the associated handles, this will

achieve best performance by decreasing

the amount of context-switches done...

Usage of BeginSend/BeginRecieve may ( internally ) use the IO Completion mechanism BUT doesn't enable
the usage of a [SINGLE] IO Completion port for several asynchronous tasks, SOooo it doesn't fit the same
manner described above... what should I do to achieve the functionality just described using the .NET
framework???? any pointers/samples or ideas will be appreciated.

Why do you think that BeginSend/BeginReceive will use more that one IO
Completion port?

To get the functionality you described, use BeginSend/BeginReceive.

I think Job Objects are the only thing that would really require you to
create your own IO Completion port.

John Vottero

 

[Guest]

Thankd for your responce,

Why do you think that BeginSend/BeginReceive will use more that one IO
Completion port?

Well, I Would excpect that usage of a single IO completion port will enable binding Stream objects ( e.g. FileStream ) to the ThreadPool object ( which uses a single IO Completion port ) preventing this, means that a process that use a ThreadPool and a Stream object will utilize [AT-LEAST] two Completion ports ( one for the stream and one for the ThreadPool )... Enabling association of stream objects with a ThreadPool will enable to achieve better performence...

 

[John Vottero]

Thankd for your responce,
Well, I Would excpect that usage of a single IO completion port will

enable binding Stream objects ( e.g.

FileStream ) to the ThreadPool object ( which uses a single IO Completion

port ) preventing this, means that a

process that use a ThreadPool and a Stream object will utilize [AT-LEAST]

two Completion ports ( one for the

stream and one for the ThreadPool )... Enabling association of stream

objects with a ThreadPool will enable to

achieve better performence...

When you call BeginRead or BeginWrite you are binding to a thread pool but
the Framework does it all under the covers. The AsyncCallback method that
you pass to BeginRead or BeginWrite is called on a ThreadPool thread. You
can open a thousand streams and issue a thousand BeginReads and you WON'T
have a thousand threads waiting.

ThreadPool also has the BindHandle method that binds a handle to the
ThreadPool. This associates the handle with the ThreadPool's IO Completion
port. You usually don't want to use that, you should use
BeginRead/BeginWrite on a stream or, if you have a handle (i.e. to a named
pipe), create a FileStream with the constructor that takes a handle and set
the "isAsync" parameter to the constructor to true. That handle will be
bound to the ThreadPool's completion port and you can use
BeginRead/BeginWrite.

As far as I know, the ThreadPool only uses one IO Completion port. It might
use more than one if it is trying to optimize throughput, for example, it
might use one IO Completion port for every CPU. The important thing is that
you don't care, the Framework is doing the "right thing".

 

[Guest]

Well, Thanks for your detailed response, I wonder... is there any 'formal' Microsoft documentation that explain how all Async Stream functionality is implemented in terms of IO Completion ports? Does what you say is based on some formal documentation or on common good scenes?

P.S.
Personally I think that taking as granted that the framework is "doing the right thing" is one of the down sides of using .NET, One is not able to really understand how things work... and this means that optimal performance is hard to be achieved, this cause development of performance critical applications to be developed in environments other then the .NET framework..., may be the .NET framework is not designed for performance critical applications in the first place… ( I don't know )…

Thankd for your responce,
Well, I Would excpect that usage of a single IO completion port will

enable binding Stream objects ( e.g.

FileStream ) to the ThreadPool object ( which uses a single IO Completion

port ) preventing this, means that a

process that use a ThreadPool and a Stream object will utilize [AT-LEAST]

two Completion ports ( one for the

stream and one for the ThreadPool )... Enabling association of stream

objects with a ThreadPool will enable to

achieve better performence...

When you call BeginRead or BeginWrite you are binding to a thread pool but
the Framework does it all under the covers. The AsyncCallback method that
you pass to BeginRead or BeginWrite is called on a ThreadPool thread. You
can open a thousand streams and issue a thousand BeginReads and you WON'T
have a thousand threads waiting.

ThreadPool also has the BindHandle method that binds a handle to the
ThreadPool. This associates the handle with the ThreadPool's IO Completion
port. You usually don't want to use that, you should use
BeginRead/BeginWrite on a stream or, if you have a handle (i.e. to a named
pipe), create a FileStream with the constructor that takes a handle and set
the "isAsync" parameter to the constructor to true. That handle will be
bound to the ThreadPool's completion port and you can use
BeginRead/BeginWrite.

As far as I know, the ThreadPool only uses one IO Completion port. It might
use more than one if it is trying to optimize throughput, for example, it
might use one IO Completion port for every CPU. The important thing is that
you don't care, the Framework is doing the "right thing".

 

[John Vottero]

Well, Thanks for your detailed response, I wonder... is there any 'formal' Microsoft documentation that
explain how all Async Stream functionality is implemented in terms of IO

Completion ports? Does what you

say is based on some formal documentation or on common good scenes?

I haven't seen any detailed documentation in this area. Figuring out how
BindHandle works took a fair amout of guessing and testing.

P.S.
Personally I think that taking as granted that the framework is "doing the

right thing" is one of the down sides

of using .NET, One is not able to really understand how things work... and this means that optimal
performance is hard to be achieved, this cause development of performance critical applications to be
developed in environments other then the .NET framework..., may be the

..NET framework is not designed for

performance critical applications in the first place. ( I don't know ).

Similar statements have been made about every advance in software
development. I'm sure you can get much better program performance out of
C++ code but, you get much better programmer performance with C#.

 

[Guest]

Thanks for your response, it is very helpful, So, can I conclude from what you are saying that ...ThreadPool.BindHandle is being called by Stream Objects ( e.g. FileStream ) upon async usage? do you know of any good .NET profiling tools that can verify this assumption? ( is it an assumption? )

Nadav
http://www.ddevel.com

 

[John Vottero]

Thanks for your response, it is very helpful, So, can I conclude from what you are saying
that ...ThreadPool.BindHandle is being called by Stream Objects ( e.g.

FileStream ) upon async usage? do

you know of any good .NET profiling tools that can verify this assumption?

( is it an assumption? )

I've seen several posts by Microsoft employees who state that
BeginRead/BeginWrite use IO Completion ports. I haven't seen a good
explaination of how they are used.

I don't know of any good .NET profiling tools but, for this test, you could
use Task Manager. Write a test that will open 1000 sockets, issue 1000
BeginReads (that will stall) and then look at your thread count.