Why socket is disposed when

Question

0.00/5 (No votes)

See more:

Dear All:

Code:

C#

While(tcpClient.Available >0)
{
  // todo: read contents
    Thread.Sleep(0);
}

The problem is

when call Thread.Sleep(0).

the tcpClient will be disposed.

the tcpClient.Available will throw exception.

Thanks.

Posted 20-Aug-12 5:57am

Sam_lin

Updated 20-Aug-12 6:17am

Wes Aday

v2

Add a Solution

Comments

[no name] 20-Aug-12 12:01pm

That makes no sense at all. Calling Sleep will not dispose your connection for you.

Sergey Alexandrovich Kryukov 20-Aug-12 12:31pm

Basically, you are right, but it might indirectly manifest already existing problem in a wrong code, if some race condition is present. Please see the explanation in my answer.
--SA

ridoy 20-Aug-12 12:24pm

Question isn't clear..what you need to do here?

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2012-08-20T06:29:00

Solution 1

The problem, if any, is somewhere else. Yes, I'm 100% sure.

I little clarification: Thread.Sleep(0) is not equivalent to "no operation" or the code where this line is missing. To best of my knowledge, it takes some time for the method call, it cause switching the calling thread off and preemption by some other thread (perhaps one-time), and the actual delay is some random delay more then zero. It could not possibly disrupt operation of your thread.

However, it can indirectly manifest some problem with some probability, if you whole code design is wrong due to race condition you might embed in your design. I prefer more descriptive term "incorrect dependency on the time of execution". Please see:
http://en.wikipedia.org/wiki/Race_condition[^].

To start the investigation, you should learn about threading and parallel design from this point of view. You did not provide us enough information to help you.

—SA

Posted 20-Aug-12 6:29am

Sergey Alexandrovich Kryukov

Updated 20-Aug-12 19:04pm

v2

Comments

AmitGajjar 21-Aug-12 1:03am

5+ thanks for Thread.Sleep(0) explanation.

Sergey Alexandrovich Kryukov 21-Aug-12 14:19pm

Thank you, Amit.
--SAq

Kuthuparakkal 21-Aug-12 1:32am

great solution... so much to learn from you SA

Sergey Alexandrovich Kryukov 21-Aug-12 14:19pm

Thank you very much for your nice words.
--SA

Sam_lin 21-Aug-12 11:55am

i know what you mean, when call Thread.Sleep(0),There is a chance for opration system to switch another thread. That's said, another thread will close the socket.

i will check the whole code. Thanks.

But i want to make sure that "Thread.Sleep(0)" dosen't dispose any resource,right?

Thanks.

Sergey Alexandrovich Kryukov 21-Aug-12 14:30pm

Right, it cannot change anything in resource or whatever else, can only affect timing. If this call effects any operation logically, it means there is a race condition. Imagine that one thread adds 3 to some integer object, and another one multiplies the same object by 4. Even though if everything is correctly synchronized, the final result depends on which thread comes first, that is, the result is unpredictable. This is the race condition. It's a good idea to work with every socket or a network stream in one thread, but one thread can and usually should handle just one socket.

It does not mean you cannot share sockets between threads at all. On server end, the typical schema is: one thread is listening for new connections, and one more (or few threads) is working with network streams through the sockets, so the socket collection should be interlocked (using .NET lock, or something).

About closing sockets: I developed the practice to close sockets only on exceptions (+ on exit). Say, when a client terminates, the server side gets exception while trying to send data to the remote socket. Here is why: unpredicted closing of connections are unavoidable in principle (if a client computer looses power accidentally, you will get the same exception), so you can use unified closing mechanism for all connections, without the need for "graceful" disconnection. However, if it is essential to distinguish between graceful and accidental losses of connection, add some graceful mechanism in application-level protocol...

--SA

Sergey Alexandrovich Kryukov 21-Aug-12 14:31pm

Anyway, if you agree it makes sense, please accept the answer formally (green button) -- thanks.
--SA

Sam_lin 21-Aug-12 22:50pm

Thanks,SA

Sergey Alexandrovich Kryukov 22-Aug-12 0:49am

You are very welcome.
Good luck, call again.
--SA