c# - Is safe to call NetworkStream.BeginWrite multiple times from one thread? -

i implementing tcp client in unity3d game , wondering if it's safe or not call networkstream.beginwrite without waiting until previous call finishes writing.

from understood while reading documentation, it's safe until not performing concurrent beginwrite calls in different threads (and unity has 1 thread game main loop).

for reading call beginread right after making connection asynchronous callback in read incoming data tcpclient.getstream(), put separate memorystream lock(readmemorystream), , run beginread again. besides that, in update() function (in main game thread) check new data in readmemorystream, check solid message , unpack (using same lock(readmemorystream) of course) , perform operations on game objects based on message server.

will approach work fine? won't beginread interfere beginwrite? again, using callback thread read data , main thread write.

as long no 2 threads calling beginwrite() concurrently, well. same thread, or other threads, can call beginwrite() consecutively before earlier calls have completed.

do note completion callbacks might executed out of order; if implement way , order of execution of completion callbacks matters, keep track of asynchronous operation which. of course, writing socket, doesn't matter, may not have in completion callback other call endwrite().

reading , writing socket independent operations. socket full-duplex , can safely handle concurrently pending read , write operations on same socket.

didn't ask, beginwrite(), can call beginread() multiple times without earlier operations completing. , again, beginwrite(), it's keep track of correct order of operations when completion callback executed each one, know order received data should in.

note since order of completions critical read operations (something not case write operations), common largest-scale implementations never overlap read operations on given socket. code simpler when given socket, 1 read operation in progress @ time.

1 last caveat: note buffers pinned duration of i/o operation. many outstanding i/o operations can interfere efficient management of heap, due fragmentation. unlikely issue in client implementation, large-scale server implementation should take account (e.g. allocating large buffers come loh, things pinned anyway).