Can running multiple asynchronous read / write operations on the same thread spoil the data?

Question

I use asynchronous I / O because it does not block the calling thread and does not execute threading behind the scenes. If I call several asynchronous operations, such as BeginWrite () in the same thread, should I worry that the contents of the buffer contents are mixed?

Suppose I want to send 3 buffers:

Buffer1: 1111111111 Buffer2: 2222222222 Buffer3: 3333333333 

I don't mind if the buffers are sent in the wrong order, so

 333333333311111111112222222222 

OK, but is it possible that the contents of the buffer are completely mixed?

 122213121212122333313111223333 

PS: I am 100% sure that someone has already asked about this in some form ...

Answer 1

It depends on the implementation of Stream. For example, sockets support multiple overlapping requests for both reading and writing, as well as a file API. They guarantee the consistency of each operation (without the contents of the interleave), as well as the order of operations: for example, to read sockets, the received bytes will be placed in buffers placed in the sent order. If these guarantees were not provided, it would not be possible to write a high-performance network application because overlapping submissions are required, but overlapping recipients are actually necessary for high-performance network I / O. This behavior is described in many articles, including the good ole Windows Sockets 2.0: write scalable Winsock applications using completion ports and is documented on MSDN

Both sending and receiving operations may be blocked. The receive function can be called several times for publishing to receive buffers in preparation for incoming data and the send function can be called several times in a queue to send several buffers. Note that while a series of overlapping message buffers will be sent in the order delivered, the corresponding completion of readings may occur in another order. Similarly, upon receipt of the side, the buffers will be filled in; they are delivered, but completion indications may arise in a different order.

Not surprisingly, the same guarantees carry over to the manageable side of the world, for example. NetworkStream class:

Read and write operations can be performed simultaneously on an instance of the NetworkStream class without the need for synchronization. As long as there is one unique thread for write operations and one unique thread for read operations, there will be no crosstalk between read and write streams and no synchronization is required.

Saying that random asynchronous reading and writing to the stream will lead to fast chaos. Applications need to carefully arrange the order in which threads transfer operations so that the order is deterministic. This usually means keeping records in the (synchronized) list with extreme care in order to invoke the async operation while holding the synchronization lock.

In conclusion, we note that all of these asynchronous APIs make a special note, calling that the completion order is not guaranteed according to the sending order.

Answer 2

No, file streams do not support multiple concurrent IOs. The Windows file system cannot handle this. This will almost certainly cause an exception.

Edit:

Syncing and overlapping input and output seems to indicate that the file system will correctly handle multiple overlapping I / O requests. My bad.

However, do not attempt to perform simultaneous synchronous recording on a FileStream . This throws an exception.