Hi,

I am doing as shown below below. Now since for every client that
connects a new call is being made, when a client finishes the
CloseClientCommunication method is called. In case two clients or more
clients terminate communication simulateneously, what would be the
behaviour of the CloseClientCommunication method.

Also, as given in the ClientCommunication method, the clientID is being
given as a parameter in the method and finally is being returned. Is
there a way to avoid the need of having to return this clientID?

pubilc delegate int ClientCommunicationDelegate(int clientID);

while(true)
{
Socket client = listener.AcceptSocket();
if (client.Connected == true)
{
ClientCommunicationDelegate del = new
ClientCommunicationDelegate(this.ClientCommunication);
AsyncCallback cb = new AsyncCallback(this.CloseClientCommunication);
IAsyncResult ar = del.BeginInvoke(this.totalClients, cb, null);
totalClients++; } // end if
} // end while loop

public int ClientCommunication(int clientID)
{
...
return clientID;
}

public void CloseClientCommunication(IAsyncResult ar)
{
while (ar.AsyncWaitHandle.WaitOne() == false){}

ClientCommunicationDelegate del =
(ClientCommunicationDelegate)((AsyncResult)ar).AsyncDelegate;
int clientID = del.EndInvoke(ar);
}

Can someone help me out
Thanks in Advance

(E-Mail Removed) wrote:
> Hi,
>
> I am doing as shown below below. Now since for every client that
> connects a new call is being made, when a client finishes the
> CloseClientCommunication method is called. In case two clients or more
> clients terminate communication simulateneously, what would be the
> behaviour of the CloseClientCommunication method.
>
> Also, as given in the ClientCommunication method, the clientID is being
> given as a parameter in the method and finally is being returned. Is
> there a way to avoid the need of having to return this clientID?
>
> pubilc delegate int ClientCommunicationDelegate(int clientID);
>
> while(true)
> {
> Socket client = listener.AcceptSocket();
> if (client.Connected == true)
> {
> ClientCommunicationDelegate del = new
> ClientCommunicationDelegate(this.ClientCommunication);
> AsyncCallback cb = new AsyncCallback(this.CloseClientCommunication);
> IAsyncResult ar = del.BeginInvoke(this.totalClients, cb, null);
> totalClients++; } // end if
> } // end while loop
>
> public int ClientCommunication(int clientID)
> {
> ...
> return clientID;
> }
>
> public void CloseClientCommunication(IAsyncResult ar)
> {
> while (ar.AsyncWaitHandle.WaitOne() == false){}
>
> ClientCommunicationDelegate del =
> (ClientCommunicationDelegate)((AsyncResult)ar).AsyncDelegate;
> int clientID = del.EndInvoke(ar);
> }
>
> Can someone help me out
> Thanks in Advance
>

bernard,

You should read up on threading Design
http://msdn.microsoft.com/library/de...guidelines.asp
.. What you are talking about is deadlock and can produce some bad, and
difficult to debug bugs in your application. What you will need to do
is use a Mutex to synchronize access.

--
Rob Schieber

Rob Schieber <(E-Mail Removed)> wrote:

<snip>

> You should read up on threading Design
> http://msdn.microsoft.com/library/de...library/en-us/
> cpgenref/html/cpconthreadingdesignguidelines.asp
> . What you are talking about is deadlock and can produce some bad, and
> difficult to debug bugs in your application. What you will need to do
> is use a Mutex to synchronize access.

Using an actual Mutex is usually overkill unless interprocess
communication is required. Using the "lock" statement
(Monitor.Enter/Exit) is more efficient as it's a "managed" concept with
no need to go down to Win32 concepts.

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Hi,

I read some pages from the link given, but I am note sure if I
understood well.

If I have a method that is called twice using two different threads

private void myMethod() {......}

Thread t1 = new Thread(new ThreadStart(myMethod);
Thread t2 = new Thread(new ThreadStart(myMethod);
t1.Start(); t2.Start();

If I'm correct, threads share memory. This applies for global
variables. In case of method class, should the two threads calling the
same method that I created conflict with each other, even if they are
accessing no global variables?

On 28 Sep 2005 23:36:53 -0700, (E-Mail Removed) wrote:

>Hi,
>
>I read some pages from the link given, but I am note sure if I
>understood well.
>
>If I have a method that is called twice using two different threads
>
>private void myMethod() {......}
>
>Thread t1 = new Thread(new ThreadStart(myMethod);
>Thread t2 = new Thread(new ThreadStart(myMethod);
>t1.Start(); t2.Start();
>
>If I'm correct, threads share memory. This applies for global
>variables. In case of method class, should the two threads calling the
>same method that I created conflict with each other, even if they are
>accessing no global variables?

If two threads access the same memory on the Heap at the same time a
memory conflict can occur. (Note: Problems usually only occur if
atleast one thread are changing values on the Heap)

So what is on the Heap?
* Each object instance has space reserved for it on the heap. This
space contains all instance variables. (Note: If the variable is of a
reference type it simply contains a memory pointer that points to
another place on the heap.
* Each class also has space reserved for it on the heap. This space
contains all static variables.

The opposite of the Heap is the Stack. Each thread has its own stack
which contains:
* local variables and parameters
(Note: As mentioned before, if the variable is of a reference type,
there is only a memory pointer that points to the Heap)

Example:

class MyClass
{
public int MyValue;
}

class AnotherClass
{
public MyClass MyInstance;
}

class AThirdClass
{

int instanceVar;

public MyMethod(AnotherClass obj, int b)
{
// c is on stack so this isn't a problem.
int c = 10;
// d is a memory pointer on the stack.
// It is pointing to a MyClass object on the Heap.
// Since the object is newly created, no other threads can have
// access to it
MyClass d = new MyClass();

// Here is a potential problem. We are changing a MyInstance
// pointer on the Heap. This is a problem if another thread is
// accessing object obj at the same time.
obj.MyInstance = d;
// Also a problem. This also changes something on the heap.
obj.MyInstance.MyValue

// Another problem. instanceVar belongs to the current instance of
// AThirdClass so it is on the heap. If another thread is calling
// this method using the same object instance there could
// be a collision.
instanceVar = instanceVar+1;
}
}

--
Marcus Andrén