.NET C# Socket Concurrency issues

views:

460

answers:

.NET C# Socket Concurrency issues

An instance of System.Net.Sockets.Socket

can be shared by 2 threads so one use the send() method and another it's receive() method ?

Is it safe?

Well, I need it to be not only thread-safe, but also that the send/receive methods be non-syncronized, so as to let each thread call them concurrently.

Do I have another way of doing it ?

Thanks for helping, I am experienced in java but having a hard time trying to make this one.

+2 A:

It should be safe, yes. The Socket class is quoted by MSDN to be fully thread-safe.

I don't know if it's a good idea however. You might be making it difficult for yourself by using two threads. You probably want to look at BeginSend and BeginReceive for asynchronous versions, in which case you shouldn't need multiple threads.

Thorarin 2009-08-26 20:01:32

First, I am concerned not only about the thread-safety, but also the concurrent use of read/write. and Hmm, ok, let me ask something more please answer me. Under the hood, the use of those async methods manages another thread to achieve the asincronicity rigth ? If so, each time I call begin..., will it create a new thread ?

David Hofmann 2009-08-26 20:12:29

As far as I know, a new thread is created, but it won't be a new thread for every single call. I did a little test to confirm, and it sure looks that way.

Thorarin 2009-08-26 21:02:52

Any reference please :D

David Hofmann 2009-08-26 21:20:04

I believe that the async methods use threadpool threads, rather than creating a specific new thread

Matt 2009-08-27 01:18:29

@Matt: That's true. It might or might not start a new thread, depending on the availability of idle threads in the thread pool. The distinction is usually not relevant, so I left it out originally. Some info here: http://msdn.microsoft.com/en-us/library/ms973903.aspx

Thorarin 2009-08-27 05:00:14

+1 A:

Yes, it is perfectly safe to access send and recieve from two different threads at the same time.

If you want your application to scale to 100's of active sockets then you'll want to use the BeginReceiveve/BeginSend methods as opposed to creating threads manually. This will do magic behind the scenes so that you don't spawn 100's of threads to process the sockets. What exactly it does is platform dependent. On windows you'll use the 'high performance' io completion ports. Under linux (mono) you'll use epoll I believe. Either way, you'll end up using a lot less threads than active sockets, which is always a good thing :)

Alan 2009-08-26 22:33:20

Why do you say that using a dedicated thread for receiving/sending will impose a greather latency or impose an scalability problem than using the async methods ?

David Hofmann 2009-08-27 14:12:32

Suppose you have 500 open sockets and you're only receving from them. You'd need to spin up 500 threads, each of them blocking on Socket.Receive ().Now, suppose you used the asynchronous BeginReceive version of the method. The .NET runtime will hand the sockets to the OS and say "Tell me when they have data". When they have data, the runtime will grab a thread from the threadpool and invoke the AsyncCallback so you can process your data.This is a *lot* more performant than context switching 500 threads.

Alan 2009-08-30 11:38:33

ansaurus

tags:

views:

answers:

.NET C# Socket Concurrency issues

related questions