c# - How does .NET handle IOCP thread safety? -

i'm playing socketasynceventargs , io completion ports. i've been looking can't seem find how .net handles race conditions.

need clarification on stack overflow question: https://stackoverflow.com/a/28690948/855421

as side note, don't forget request might have completed synchronously. perhaps you're reading tcp stream in while loop, 512 bytes @ time. if socket buffer has enough data in it, multiple readasyncs can return without doing thread switching @ all. [emphasis mine]

for sake of simplicity. let's assume 1 client 1 server. server using iocp. if client fast writer server slow reader, iocp mean kernel/underlying process can signal multiple threads?

1 so, socket reads 512 bytes, kernel signals iocp thread 2 server processes new bytes 3 socket receives x bytes server still processing previous buffer

does kernel spin thread? socketasynceventargs has buffer definition is: "gets data buffer use asynchronous socket method." buffer should not change on lifetime of socketasynceventargs if understand correctly.

what's preventing socketasynceventargs.buffer getting corrupted iocp thread 2?

or .net framework synchronize iocp threads? if so, what's point of spinning new thread if iocp thread 1 blocks previous read?

i've been looking can't seem find how .net handles race conditions.

for part, doesn't. it's that. but, it's not clear question have race condition problem.

you asking text, in the other answer:

if socket buffer has enough data in it, multiple readasyncs can return without doing thread switching @ all

first, clear: method's name receiveasync(), not readasync(). other classes, streamreader , networkstream have readasync() methods, , these methods have little question about. now, clarified…

that quote opposite of race condition. author of text warning that, should happen call receiveasync() on socket has data ready read, data read synchronously , socketasynceventargs.completed event not raised later. responsibility of thread called receiveasync() process data read.

all of happen in single thread. there wouldn't race condition in scenario.

now, let's consider "fast writer, slow reader" scenario. worst can happen there first read, take place in thread, not complete immediately, time completed event raised, writer has overrun reader's pace. in case, since part of handling completed event calling receiveasync() again, return synchronously, iocp thread pool thread tied looping on calls receiveasync(). no new thread needed, because current iocp thread doing work synchronously. does prevent thread handling other iocp events.

all mean though, if have other socket server handling , needs call receiveasync(), framework have ensure there's thread in iocp thread pool available handle i/o. but, that's different socket , using different buffer socket anyway.

again, no race condition.

now, said, if want really confused, is possible use asynchronous i/o in .net socket api (whether beginreceive() or receiveasync() or wrapping socket in networkstream , using readasync()) in such way do have race condition particular socket.

i hesitate mention it, because there's no evidence in question pertains @ all, nor you're interested in having level of detail. adding explanation confuse things. but, sake of completeness…

it possible have issued more 1 read operation on socket @ given time. akin double- or triple-buffered video display (if you're familiar concept). idea being might still handling read operation while new data comes in, , more performant have new read operation in progress handle data before you're done handling current read operation.

this sounds great, in practice because of way windows schedules threads, , in particular not guarantee particular ordering of thread scheduling, if try implement code way, create possibility your code see read operations completed out of order. is, if example call receiveasync() twice in row (with 2 different socketasynceventargs objects , 2 different buffers, of course), completed event handler might called second buffer first.

this isn't because read operations complete out of order. don't. hence emphasis on "your" above. problem while iocp threads handling io completions become runnable in correct order (because buffers filled in order provided them calling receiveasync() multiple times), second iocp thread become runnable wind being first thread scheduled run windows.

this not hard deal with. have make sure track buffer sequence issue read operations, can reassemble buffers in correct order later. of async options available provide mechanism include additional user state data (e.g. socketasynceventargs.usertoken), can use track order of buffers.

again, not common. scenarios, orderly implementation, issue new read operation after you're done current read operation, sufficient. if you're worried @ getting multi-buffer read implementation correct, don't bother. stick simple approach.