Question abut threads

On Aug 7, 1:25*pm, "Markgoldin " <markgoldin_2.. .@yahoo.comwrot e:

I am working on a program that creates a few TCP listenrs to accept data
from non .net processes.
Each listener listens in its own thread. I am using Thread.Sleep(10 00) to
let other threads work.
Here is my code:
tcpl = new TcpListener(ipe );
TcpClient tcpc = tcpl.AcceptTcpC lient();
while (true)
{
* * // get data
* * while (true)
* * {
* * * * // if contidion met break;
* * }
* * Thread.Sleep(10 00) ;

}

Do I really need Thread.Sleep(10 00) ? What would happend if I dont use itat
all?

That depends on what happens in the loop. Are you actually likely to
be processor bound? Is your while loop a tight loop? If so, that's the
thing to fix.

It's unlikely that you should really be sleeping, but if you ever need
to wait for a condition to be met, you should probably be using an
Auto/ManualResetEven t or Monitor.Wait/Pulse.

Jon

On Aug 7, 8:25*am, "Markgoldin " <markgoldin_2.. .@yahoo.comwrot e:

I am working on a program that creates a few TCP listenrs to accept data
from non .net processes.
Each listener listens in its own thread. I am using Thread.Sleep(10 00) to
let other threads work.

you should only do this if each listener listen in a different post.

Here is my code:
tcpl = new TcpListener(ipe );
TcpClient tcpc = tcpl.AcceptTcpC lient();
while (true)
{
* * // get data
* * while (true)
* * {
* * * * // if contidion met break;
* * }
* * Thread.Sleep(10 00) ;

}

Do I really need Thread.Sleep(10 00) ? What would happend if I dont use itat
all?

why you use it in the first place??

Answer to this, are you using one port or multiple ports?
I can give you code in each case, it's as simple as using a SyncQueue.
and one thread per connection (no per listener)

On Thu, 07 Aug 2008 08:04:03 -0700, Ignacio Machin ( .NET/ C# MVP )
<ig************ @gmail.comwrote :

On Aug 7, 8:25Â*am, "Markgoldin " <markgoldin_2.. .@yahoo.comwrot e:

>I am working on a program that creates a few TCP listenrs to accept data
from non .net processes.
Each listener listens in its own thread. I am using Thread.Sleep(10 00)
to
let other threads work.

you should only do this if each listener listen in a different post.

I believe Ignacio has a one-letter type here: "post" should be "port".
Hopefully that was clear from the rest of his message, but if not this
should clear it up. :)

[...]

>Do I really need Thread.Sleep(10 00) ? What would happend if I dont use
it at
all?

why you use it in the first place??

Answer to this, are you using one port or multiple ports?
I can give you code in each case, it's as simple as using a SyncQueue.
and one thread per connection (no per listener)

I don't find the type "SyncQueue" in the MSDN documentation, so I don't
know what Ignacio is getting at. That said, I'll suggest that there are
really only two viable approaches to TCP network i/o in .NET:

-- one thread per connection, using blocking i/o
-- asynchronous API (e.g. Socket.BeginRec eive(), etc.)

(For i/o using the Socket class directly, there is a Select() method
similar to BSD sockets's select() function which is theoretically simpler
than the asynchronous API, but personally I think it's both awkward and
inefficient. .NET has much better i/o paradigms to take advantage of).

The former can be the simplest, assuming each connection is completely
independent from each other. But it's only appropriate for relatively
small numbers of remote endpoints (hundreds, at the very most). The
latter is much more scalable, and more importantly, most implementations
other than the "one thread per connection" design are going to wind up
involving some similar thread management issues anyway. One might as well
use the built-in threaded i/o rather than reinventing the wheel.

MSDN has code samples for the asynchronous API both in the Socket class
and, if I recall correctly, the TcpListener/TcpClient classes.

Pete

On Aug 7, 12:34*pm, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Thu, 07 Aug 2008 08:04:03 -0700, Ignacio Machin ( .NET/ C# MVP ) *

<ignacio.mac... @gmail.comwrote :

On Aug 7, 8:25*am, "Markgoldin " <markgoldin_2.. .@yahoo.comwrot e:

I am working on a program that creates a few TCP listenrs to accept data
from non .net processes.
Each listener listens in its own thread. I am using Thread.Sleep(10 00)*
to
let other threads work.

you should only do this if each listener listen in a different post.

I believe Ignacio has a one-letter type here: "post" should be "port". *
Hopefully that was clear from the rest of his message, but if not this *
should clear it up. *:)

Sorry for the mistake, I also noticed a couple of words in spanish in
another post, I've been without coffee the entire morning, not good
for health :)

I don't find the type "SyncQueue" in the MSDN documentation, so I don't *
know what Ignacio is getting at. *That said, I'll suggest that there are *
really only two viable approaches to TCP network i/o in .NET:

There is none, but you have Queue.Synchroni zed method:
Returns a Queue wrapper that is synchronized (thread safe).

Seet his example:
Queue connectionQueue ;
protected override void OnStart(string[] args)
{
listenerThread = new Thread( new ThreadStart( ListenerMethod) );
listenerThread. Start();
}
protected void ListenerMethod( )

{
Thread workingthread;
Queue unsyncq = new Queue();
connectionQueue = Queue.Synchroni zed( unsyncq);
TcpClient socket;
TcpListener listener = new TcpListener( 1212);

listener.Start( );
while( true)
{
socket = listener.Accept TcpClient();
connectionQueue .Enqueue( socket);
workingthread = new Thread( new
ThreadStart( TheConnectionHa ndler));
workingthread.S tart();
}
}
public void TheConnectionHa ndler()
{
TcpClient socket= (TcpClient)conn ectionQueue.Deq ueue();
//use the socket
}

On Thu, 07 Aug 2008 11:18:01 -0700, Ignacio Machin ( .NET/ C# MVP )
<ig************ @gmail.comwrote :

[...]

>I don't find the type "SyncQueue" in the MSDN documentation, so I don't
know what Ignacio is getting at. Â*That said, I'll suggest that there
are Â*
really only two viable approaches to TCP network i/o in .NET:

There is none, but you have Queue.Synchroni zed method:
Returns a Queue wrapper that is synchronized (thread safe).

Seet his example:

All due respect and no offense intended, but... yuck! :)

You're using the queue just as a way of passing data from one thread to
another? What's wrong with using ParameterizedTh readStart? For example:

protected void ListenerMethod( )
{
TcpListener listener = new TcpListener(121 2);

listener.Start( );
while (true)
{
TcpClient client = listener.Accept TcpClient();

new Thread(TheConne ctionHandler).S tart(client);
}
}

protected void TheConnectionHa ndler(object objArg)
{
TcpClient client = (TcpClient)objA rg;

//...
}

Notes:

-- I prefer to use the variable name "socket" only when it's actually
a Socket instance. TcpClient wraps a Socket, and can be used in similar
ways. But it's not really a Socket and thinking it is could lead to some
confusion.

-- The compiler can infer the correct type for the Thread constructor
and create the delegate for you, so you don't actually need to explicitly
specify "new ThreadStart(... )" or "new ParameterizedTh readStart(...)" when
creating the Thread instance.

A slight variation on the above theme would be to capture the "client"
variable in an anonymous method and avoid casting altogether:

protected void ListenerMethod( )
{
TcpListener listener = new TcpListener(121 2);

listener.Start( );
while (true)
{
TcpClient client = listener.Accept TcpClient();

new Thread(delegate { TheConnectionHa ndler(client) }).Start();
}
}

protected void TheConnectionHa ndler(TcpClient client)
{
//...
}

I still prefer the asynchronous methods. But the above are, I think, at
least more appropriate than creating a queue just for the purpose of
moving a single reference from one thread to another.

Just my two cents.

Pete

On Thu, 07 Aug 2008 11:33:48 -0700, Peter Duniho
<Np*********@nn owslpianmk.comw rote:

[...]
new Thread(delegate { TheConnectionHa ndler(client)
}).Start();

Sorry...forgot a semi-colon there. I assume the reader can easily fix
that, but just in case:

new Thread(delegate { TheConnectionHa ndler(client); }).Start();

Instead of using threads to keep client state, you may want to look into
using async comm. The fx3.5 has some improvements in socket class that may
help:
http://msdn.microsoft.com/en-us/magazine/cc163356.aspx
--wjs

"Markgoldin " <ma************ *@yahoo.comwrot e in message
news:eV******** ********@TK2MSF TNGP06.phx.gbl. ..

>I am working on a program that creates a few TCP listenrs to accept data
from non .net processes.
Each listener listens in its own thread. I am using Thread.Sleep(10 00) to
let other threads work.
Here is my code:
tcpl = new TcpListener(ipe );
TcpClient tcpc = tcpl.AcceptTcpC lient();
while (true)
{
// get data
while (true)
{

....

On Aug 7, 2:33*pm, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Thu, 07 Aug 2008 11:18:01 -0700, Ignacio Machin ( .NET/ C# MVP ) *

<ignacio.mac... @gmail.comwrote :

[...]

I don't find the type "SyncQueue" in the MSDN documentation, so I don't *
know what Ignacio is getting at. *That said, I'll suggest that there*
are *
really only two viable approaches to TCP network i/o in .NET:

There is none, but you have Queue.Synchroni zed *method:
Returns a Queue wrapper that is synchronized (thread safe).

Seet his example:

All due respect and no offense intended, but... *yuck! *:)

You're using the queue just as a way of passing data from one thread to *
another? *What's wrong with using ParameterizedTh readStart? *For example:

No offense taken :)

You are right, you can use ParameterizedTh readStart . The thing is
that that piece of code is from 1.1 era , you had no
ParameterizedTh readStart back then :)
This is the original post:

http://groups.google.com/group/micro...eabe586c0924e0

Just recently I updated it to 2005 but the code is the same, it works,
so why change it ? :)

* * *protected void ListenerMethod( )
* * *{
* * * * *TcpListener listener = new TcpListener(121 2);

* * * * *listener.Start ();
* * * * *while (true)
* * * * *{
* * * * * * *TcpClient client = listener.Accept TcpClient();

* * * * * * *new Thread(delegate { TheConnectionHa ndler(client) }).Start();
* * * * *}
* * *}

* * *protected void TheConnectionHa ndler(TcpClient client)
* * *{
* * * * *//...
* * *}

That would be the best solution :)

On Fri, 08 Aug 2008 08:03:54 -0700, Ignacio Machin ( .NET/ C# MVP )
<ig************ @gmail.comwrote :

[...]
Just recently I updated it to 2005 but the code is the same, it works,
so why change it ? :)

For your own use? I see no reason to change it. For the purpose of
providing suggestions to others? I'm sure you can figure out what _I_
think... :)

For what it's worth, even in 1.1 I think there are better approaches. For
example:

class MainClass
{
// Since in 1.1 we wouldn't have this delegate type, define
// it ourselves.
delegate void ParameterizedTh readStart(objec t objParameter);

class ThreadWithParam eter
{
ParameterizedTh readStart _start;
object _objParameter;

public ThreadWithParam eter(Parameteri zedThreadStart start,
object objParameter)
{
_start = start;
_objParameter = objParameter;
}

public void StartMethod()
{
_start(_objPara meter);
}
}

void MethodThatStart sThread()
{
object objParameter = new object(); // or whatever you want
ThreadWithParam eter twp =
new ThreadWithParam eter(
new ParameterizedTh readStart(Desir edThreadStart),
objParameter);

new Thread(new ThreadStart(twp .StartMethod)). Start();
}

void DesiredThreadSt art(object objParameter)
{
// do some work in a thread
}
}

(The "ThreadWithPara meter" class doesn't actually need to be nested as
above. Though, if you want to tie the class more closely to whatever code
is actually running the thread, that could make it more convenient).

To me, using a synchronized Queue makes a lot of sense if you're starting
multiple threads with the same entry point but each with different input.
But otherwise, it seems like overkill at best, and maybe a bit confusing
and misleading at worst. It's not _terrible_ in any case, but it does
seem awkward and not very expressive. :)

Pete