Unique copy of DLL

[tony obrien]

Hi,

I have written a Class Library in VB.net which provides Props/Meths to a
caller to hide the uglinesses of a TCP message protocol between a Client
and a Server.

All this works just fine.

Now I am trying to develop a LOAD TESTER app which spawns lotso' threads
each with this capability to bang the server.

The problerm is that the DLL class which worked just fine in a single
instance runs into problems because each version of the client-threads
seems to be reaching into the SAME copy of the DLL.

Everything I've read tells me to wrap the DLL areas that deal with
variables in SyncLocks... but this is NOT what I want... The DLL is NOT
STATELESS and so each new thread needs to have ITS OWN UNIQUE COPY of the
dll and its variables.

So the question is How Do I instantiate the DLL (class) in the thread to
ensure that it gets a NEW UNIQUE COPY running?

BTW, currently NONE of the Class's variables are public (though the
Props/Meths must be.) And the class DOES attempt to create a new copy
using...

Dim myDLLCls as theDLLClass
myDLLCls = New theDLLClass
but this does NOT generate a NEW copy in this thread.

Help !

regards,
tob

[David Browne]

"tony obrien" <tob_@_sourceco de-inc.comwrote in message
news:Xn******** *************** **********@130. 81.64.196...

Hi,

I have written a Class Library in VB.net which provides Props/Meths to a
caller to hide the uglinesses of a TCP message protocol between a Client
and a Server.

All this works just fine.

Now I am trying to develop a LOAD TESTER app which spawns lotso' threads
each with this capability to bang the server.

The problerm is that the DLL class which worked just fine in a single
instance runs into problems because each version of the client-threads
seems to be reaching into the SAME copy of the DLL.

Everything I've read tells me to wrap the DLL areas that deal with
variables in SyncLocks... but this is NOT what I want... The DLL is NOT
STATELESS and so each new thread needs to have ITS OWN UNIQUE COPY of the
dll and its variables.
. . .

That's just a design problem. If each client needs its own data, don't put
that data in shared scope. Create a class for each client to own, and place
that client's state data in the instance state of that class.

David

[tony obrien]

"David Browne" <davidbaxterbro wne no potted me**@hotmail.co mwrote in
news:#G******** ******@TK2MSFTN GP02.phx.gbl:

>

"tony obrien" <tob_@_sourceco de-inc.comwrote in message
news:Xn******** *************** **********@130. 81.64.196...

>Hi,

I have written a Class Library in VB.net which provides Props/Meths
to a caller to hide the uglinesses of a TCP message protocol between
a Client and a Server.

All this works just fine.

Now I am trying to develop a LOAD TESTER app which spawns lotso'
threads each with this capability to bang the server.

The problerm is that the DLL class which worked just fine in a single
instance runs into problems because each version of the
client-threads seems to be reaching into the SAME copy of the DLL.

Everything I've read tells me to wrap the DLL areas that deal with
variables in SyncLocks... but this is NOT what I want... The DLL is
NOT STATELESS and so each new thread needs to have ITS OWN UNIQUE
COPY of the dll and its variables.
. . .

That's just a design problem. If each client needs its own data,
don't put that data in shared scope. Create a class for each client
to own, and place that client's state data in the instance state of
that class.

David

Thanks, David...

I do not disagree BUT what seems counter intuitive is that if I were to
take the SOURCE of the DLL and include it (as a class) to the project and
let each new thread create its copy of that class it, each thread WOULD
have its own, unique copy of the data and variables... but if I create
the class separately as a DLL I CAN NOT get a unique copy??

It seems you are suggesting that Multithreaded DLLs are ALWAYS shared and
can not operate a state machines. Seems like a HUGE whole a development
capability.

tob

[David Browne]

"tony obrien" <tob_@_sourceco de-in.comwrote in message
news:Xn******** *************** **********@130. 81.64.196...

"David Browne" <davidbaxterbro wne no potted me**@hotmail.co mwrote in
news:#G******** ******@TK2MSFTN GP02.phx.gbl:

>>

"tony obrien" <tob_@_sourceco de-inc.comwrote in message
news:Xn******* *************** ***********@130 .81.64.196...

>>Hi,

I have written a Class Library in VB.net which provides Props/Meths
to a caller to hide the uglinesses of a TCP message protocol between
a Client and a Server.

All this works just fine.

Now I am trying to develop a LOAD TESTER app which spawns lotso'
threads each with this capability to bang the server.

The problerm is that the DLL class which worked just fine in a single
instance runs into problems because each version of the
client-threads seems to be reaching into the SAME copy of the DLL.

Everything I've read tells me to wrap the DLL areas that deal with
variables in SyncLocks... but this is NOT what I want... The DLL is
NOT STATELESS and so each new thread needs to have ITS OWN UNIQUE
COPY of the dll and its variables.
. . .

That's just a design problem. If each client needs its own data,
don't put that data in shared scope. Create a class for each client
to own, and place that client's state data in the instance state of
that class.

David

Thanks, David...

I do not disagree BUT what seems counter intuitive is that if I were to
take the SOURCE of the DLL and include it (as a class) to the project and
let each new thread create its copy of that class it, each thread WOULD
have its own, unique copy of the data and variables... but if I create
the class separately as a DLL I CAN NOT get a unique copy??

Yes you can. There are nested scopes in which you can declare state. You
are talking about the outermost scope: class scope. Each class you define
has a class scope (aka global, shared, static). Variables declared in this
scope, or reachable from a variable in this scope are shared among all
callers in the App Domain.

Variables declared or reachable from instance variables of a type created
separately for each client won't be shared.

It seems you are suggesting that Multithreaded DLLs are ALWAYS shared and
can not operate a state machines. Seems like a HUGE whole a development
capability.

No not at all. You can have any mix of sharing and separation of state you
want.

David

[Jon Skeet [C# MVP]]

tony obrien <tob_@_sourceco de-inc.comwrote:

I have written a Class Library in VB.net which provides Props/Meths to a
caller to hide the uglinesses of a TCP message protocol between a Client
and a Server.

All this works just fine.

Now I am trying to develop a LOAD TESTER app which spawns lotso' threads
each with this capability to bang the server.

The problerm is that the DLL class which worked just fine in a single
instance runs into problems because each version of the client-threads
seems to be reaching into the SAME copy of the DLL.

Firstly, you need to differentiate between "DLL" and "class". They're
not the same thing at all, and you seem to be treating them
interchangably.

It's fine to have one DLL, but it sounds like you probably want each
thread to have its own instance of your class. So long as none of your
variables are Shared, you should then be okay.

If that doesn't help, could you post a short but complete program which
demonstrates the problem?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[tony obrien]

Jon Skeet [C# MVP] <sk***@pobox.co mwrote in
news:MP******** *************** *@msnews.micros oft.com:

tony obrien <tob_@_sourceco de-inc.comwrote:

>I have written a Class Library in VB.net which provides Props/Meths
to a caller to hide the uglinesses of a TCP message protocol between
a Client and a Server.

All this works just fine.

Now I am trying to develop a LOAD TESTER app which spawns lotso'
threads each with this capability to bang the server.

The problerm is that the DLL class which worked just fine in a single
instance runs into problems because each version of the
client-threads seems to be reaching into the SAME copy of the DLL.

Firstly, you need to differentiate between "DLL" and "class". They're
not the same thing at all, and you seem to be treating them
interchangably.

It's fine to have one DLL, but it sounds like you probably want each
thread to have its own instance of your class. So long as none of your
variables are Shared, you should then be okay.

If that doesn't help, could you post a short but complete program
which demonstrates the problem?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.

Thanks...

In this particular case I use them interchangeably since I created a DLL
from a single Class with nothing but private variables and public
Properties and Methods.... in my mind the Class is the DLL is the Class.

sorry for the confusion.

Recently I tried bringing that class (that created the DLL) into my test
program and it still does not operate after a 2nd or 3rd thread is begun...
so perhaps I have some deeper issues going on than I thought.

I am trying to get to the smallest thing that I know has the problem.

[Jon Skeet [C# MVP]]

tony obrien <to**@sourcecod e-inc.comwrote:

In this particular case I use them interchangeably since I created a DLL
from a single Class with nothing but private variables and public
Properties and Methods.... in my mind the Class is the DLL is the Class.

sorry for the confusion.

No problem - but I think it's worth keeping the difference clear in
your head (and in your code and comments) as you never know when you'll
need another class in the same assembly.

Recently I tried bringing that class (that created the DLL) into my test
program and it still does not operate after a 2nd or 3rd thread is begun...
so perhaps I have some deeper issues going on than I thought.

I am trying to get to the smallest thing that I know has the problem.

I'm sure that when we've got a small sample we'll be able to make
progress.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[tony obrien]

tony obrien <to**@sourcecod e-inc.comwrote in
news:Xn******** *************** **********@130. 81.64.196:

Jon Skeet [C# MVP] <sk***@pobox.co mwrote in
news:MP******** *************** *@msnews.micros oft.com:

Hi Jon, (I very much appreciate your taking the time and energy to help
me thru this !)
I have been able to at least determine how the problem exhibits itself...
the very bottom has this explanation.

Below are some snippets to give you an idea of how this load tester
client operates....(an d yes I have left out gobs of code as to not bore
(overwhelm !) you... but remember this all works as a single instance so
I propose that it is in the 'multithreaded-ness' of it.)
------- IN MAIN:

'Create a new instance of the tcp interface class
aSession = New serviceConnecti on

'create a new thread
serverListenerT hread = New Threading.Threa d(AddressOf
aSession.startT hisThread)

'I then start the thread....
serverListenerT hread.Start()
------ IN THE SERVICECONNECTI ON CLASS:

=============== =============== =======
Private clientService as TCPClient
Private Event OnLineReceived( ByVal sender As serviceConnecti on, ByVal
Data() As Byte, ByVal theBytesReadCou nt As Integer)

=============== =============== =======
Public Sub StartThisThread ()

' Create an event handler to allow this serviceconnecti on class to
communicate
AddHandler OnLineReceived, AddressOf OnLineReceivedS ervice

Try
clientService = New TcpClient(mySer verNameStr$,
mSessionPortNum ber)

clientService.G etStream.BeginR ead(readBuffer, 0,
READ_BUFFER_SIZ E, AddressOf ServiceStreamRe ceiver, Nothing)
SOM = True

Catch Ex As Exception
mlastErrorStrin g = Ex.Message
Exit Sub
End Try

'Now I sit in a loop asking the SERVER for various services
=============== =============== ========
Private Sub ServiceStreamRe ceiver(ByVal ar As IAsyncResult)

Try
' Ensure that no other threads try to use the stream at the
same time.
SyncLock client.GetStrea m
' Finish asynchronous read into readBuffer and get number
of bytes read.
LCBytesRead = client.GetStrea m.EndRead(ar)
End SyncLock

RaiseEvent OnLineReceived( Me, readBuffer, LCBytesRead)

' Ensure that no other threads try to use the stream at the
same time.
SyncLock client.GetStrea m
' Start a new asynchronous read into readBuffer.
LCBytesRead = 0
client.GetStrea m.BeginRead(rea dBuffer, 0,
READ_BUFFER_SIZ E, AddressOf ServiceStreamRe ceiver, Nothing)
End SyncLock

Catch e As Exception

End Try
End Sub
=============== =============== ========

Private Sub OnLineReceivedS ervice(ByVal thisServiceConn ection As
serviceConnecti on, ByVal data() As Byte, ByVal theBytesReadCou nt As
Integer)

'This is the EVENT raised by ServiceStreamRe ceiver above....

'It gets passed the "instance" of the connection, the bytecount and
data... and this routine operates on the data.
=============== =============== ========
=============== =============== ========
=============== =============== ========

OK, so what happens is that when I start the 2nd or 3rd thread the
OnLineReceivedS ervice callback will get passed the "wrong instance" on
some response message that was received (recall that there are supposedly
distinct "thisServiceCon nection" classes created and "started".. .) and so
some instance is waiting for a response it never gets... and the instance
that does get passed throws the message away because it wasn't meant for
him.

This implies that the "wrong" instance of ServiceStreamHa ndler is being
called... perhaps the TCP.net stuff I am using does not allow me to do
what I am trying to do?

regards,
tob

[Nick Malik [Microsoft]]

With all due respect, Tony, do you have multiple threads each listening for
data on the same TCP port?

If this were the case, I fail to see how you could PREVENT contention.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"tony obrien" <tob_@_sourceco de-inc.comwrote in message
news:Xn******** *************** *********@130.8 1.64.196...

tony obrien <to**@sourcecod e-inc.comwrote in
news:Xn******** *************** **********@130. 81.64.196:

>Jon Skeet [C# MVP] <sk***@pobox.co mwrote in
news:MP******* *************** **@msnews.micro soft.com:

Hi Jon, (I very much appreciate your taking the time and energy to help
me thru this !)
I have been able to at least determine how the problem exhibits itself...
the very bottom has this explanation.

Below are some snippets to give you an idea of how this load tester
client operates....(an d yes I have left out gobs of code as to not bore
(overwhelm !) you... but remember this all works as a single instance so
I propose that it is in the 'multithreaded-ness' of it.)
------- IN MAIN:

'Create a new instance of the tcp interface class
aSession = New serviceConnecti on

'create a new thread
serverListenerT hread = New Threading.Threa d(AddressOf
aSession.startT hisThread)

'I then start the thread....
serverListenerT hread.Start()
------ IN THE SERVICECONNECTI ON CLASS:

=============== =============== =======
Private clientService as TCPClient
Private Event OnLineReceived( ByVal sender As serviceConnecti on, ByVal
Data() As Byte, ByVal theBytesReadCou nt As Integer)

=============== =============== =======
Public Sub StartThisThread ()

' Create an event handler to allow this serviceconnecti on class to
communicate
AddHandler OnLineReceived, AddressOf OnLineReceivedS ervice

Try
clientService = New TcpClient(mySer verNameStr$,
mSessionPortNum ber)

clientService.G etStream.BeginR ead(readBuffer, 0,
READ_BUFFER_SIZ E, AddressOf ServiceStreamRe ceiver, Nothing)
SOM = True

Catch Ex As Exception
mlastErrorStrin g = Ex.Message
Exit Sub
End Try

'Now I sit in a loop asking the SERVER for various services
=============== =============== ========
Private Sub ServiceStreamRe ceiver(ByVal ar As IAsyncResult)

Try
' Ensure that no other threads try to use the stream at the
same time.
SyncLock client.GetStrea m
' Finish asynchronous read into readBuffer and get number
of bytes read.
LCBytesRead = client.GetStrea m.EndRead(ar)
End SyncLock

RaiseEvent OnLineReceived( Me, readBuffer, LCBytesRead)

' Ensure that no other threads try to use the stream at the
same time.
SyncLock client.GetStrea m
' Start a new asynchronous read into readBuffer.
LCBytesRead = 0
client.GetStrea m.BeginRead(rea dBuffer, 0,
READ_BUFFER_SIZ E, AddressOf ServiceStreamRe ceiver, Nothing)
End SyncLock

Catch e As Exception

End Try
End Sub
=============== =============== ========

Private Sub OnLineReceivedS ervice(ByVal thisServiceConn ection As
serviceConnecti on, ByVal data() As Byte, ByVal theBytesReadCou nt As
Integer)

'This is the EVENT raised by ServiceStreamRe ceiver above....

'It gets passed the "instance" of the connection, the bytecount and
data... and this routine operates on the data.
=============== =============== ========
=============== =============== ========
=============== =============== ========

OK, so what happens is that when I start the 2nd or 3rd thread the
OnLineReceivedS ervice callback will get passed the "wrong instance" on
some response message that was received (recall that there are supposedly
distinct "thisServiceCon nection" classes created and "started".. .) and so
some instance is waiting for a response it never gets... and the instance
that does get passed throws the message away because it wasn't meant for
him.

This implies that the "wrong" instance of ServiceStreamHa ndler is being
called... perhaps the TCP.net stuff I am using does not allow me to do
what I am trying to do?

regards,
tob

[tony obrien]

"Nick Malik [Microsoft]" <ni*******@hotm ail.nospam.comw rote in
news:k4******** *************** *******@comcast .com:

With all due respect, Tony, do you have multiple threads each
listening for data on the same TCP port?

If this were the case, I fail to see how you could PREVENT contention.

Hi Nick,

Well,er, yeah but (ye old "yeah butt" !)

I was trying to mimic what a web browser does... my thought was that I
"publish" a known TCP port number (in this case 10,000)... clients connect
to that port number, the SERVER creates a listener for this new connection
in a new thread and starts that thread, then goes back to waiting for a new
connection on 10,000.

My understanding was that the TCP stack magically re-casts the "accepted"
client into a new internal port number and carries the conversation on
(somehow) correctly all the while. And to me this is akin to magic, but
how else *could* a server operate (such as a web browser with ONE KNOWN
port #80.)

Your thoughts?
tob