Multiple threads accessing Shared functions

VS 2003, vb.net , sql msde...

I have an application with multiple threads running. Its a telephony
application where each thread represents a telephone line. For code that
would be the same for each thread, I put in Shared methods as below. It is only now that I am realizing the complexity of multiple threads accessing
shared methods. And, quite honestly, I am very confused.

I have tried System.Threading.Monitor.Enter, Synclock, etc., and still
cannot get things to work right. Honestly, it seems to be that for each
shared method, you need to do something to lock it in the 1st line and
unlock it when you exit. Otherwise, anything at anytime can be changed at
any moment by any thread in that method.

For example, if you have a variable loaded with a value at the top of the
method, that you then set a column to that variable while adding a row, you cannot just use System.Threading.Monitor.Enter(DataRowToAdd) to protect the row your are adding, because one of the variables might change by another
thread. You would need to use System.Threading.Monitor.Enter on everything (variables, etc.) adding quite a bit of code. Even at that, I don't see
that System.Threading.Monitor.Enter stops another thread anyway.

I have spend a lot of time one this, and don't understand how to do it. Can you explain to me how to write a shared method that adds rows to a data set, and updates that dataset to the datasource, that can be used by multiple
threads at the same time. Any URLs would be helpf ul to. Maybe if I see a working example, I will grasp what is going on.

Thanks!
Bob Day

Public NotInheritable Class DL
Public Shared Sub tblMETHODS_DETAILSC_ADD_Row(ByVal
tblMethods_Summary_Row_Number_0_Based As Integer, ByVal Summary_Text As
String, Optional ByVal Details_Text As String = "")

' code to add row to table methods_details and update that row to
datasource of same name

end sub

end class

VS 2003, vb.net , sql msde...

I have an application with multiple threads running. Its a telephony
application where each thread represents a telephone line. For code that
would be the same for each thread, I put in Shared methods as below. It is only now that I am realizing the complexity of multiple threads accessing
shared methods. And, quite honestly, I am very confused.

I have tried System.Threading.Monitor.Enter, Synclock, etc., and still
cannot get things to work right. Honestly, it seems to be that for each
shared method, you need to do something to lock it in the 1st line and
unlock it when you exit. Otherwise, anything at anytime can be changed at
any moment by any thread in that method.

For example, if you have a variable loaded with a value at the top of the
method, that you then set a column to that variable while adding a row, you cannot just use System.Threading.Monitor.Enter(DataRowToAdd) to protect the row your are adding, because one of the variables might change by another
thread. You would need to use System.Threading.Monitor.Enter on everything (variables, etc.) adding quite a bit of code. Even at that, I don't see
that System.Threading.Monitor.Enter stops another thread anyway.

I have spend a lot of time one this, and don't understand how to do it. Can you explain to me how to write a shared method that adds rows to a data set, and updates that dataset to the datasource, that can be used by multiple
threads at the same time. Any URLs would be helpf ul to. Maybe if I see a working example, I will grasp what is going on.

Use a MuteX variable and then have your threads enter a wait stait for when the variable is unlocked...

"CJ Taylor" <no****@blowgoats.com> wrote in message
news:vt************@corp.supernews.com...

Use a MuteX variable and then have your threads enter a wait stait for

when

the variable is unlocked...

I belive the poster knows _how_to serialize access to a section of code.
The issue is _when_ to do so.

And SyncLock is much easier and lighter-weight than a Mutex.

David

"CJ Taylor" <no****@blowgoats.com> wrote in message
news:vt************@corp.supernews.com...

Use a MuteX variable and then have your threads enter a wait stait for

when

the variable is unlocked...

I belive the poster knows _how_to serialize access to a section of code.
The issue is _when_ to do so.

And SyncLock is much easier and lighter-weight than a Mutex.

David

You cannot put in a "Friend Shared Sub Write" method somethign like:

Friend Shared Sub Write

SyncLock Me

' code

End SyncLock

end sub

"Bob Day" <Bo****@TouchTalk.net> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...

You cannot put in a "Friend Shared Sub Write" method somethign like:

Friend Shared Sub Write

SyncLock Me

' code

End SyncLock

end sub

If you want to syncronize a shared method, you need a shared lock object.

class foo
private shared syncRoot as new object 'just something to lock
friend shared sub Write
synclock syncRoot
' code
end synclock
end sub
end class
David

"Bob Day" <Bo****@TouchTalk.net> wrote in message
news:ed**************@TK2MSFTNGP09.phx.gbl...

VS 2003, vb.net , sql msde...

I have an application with multiple threads running. Its a telephony
application where each thread represents a telephone line. For code that would be the same for each thread, I put in Shared methods as below. It is

only now that I am realizing the complexity of multiple threads accessing shared methods. And, quite honestly, I am very confused.

I have tried System.Threading.Monitor.Enter, Synclock, etc., and still
cannot get things to work right. Honestly, it seems to be that for each
shared method, you need to do something to lock it in the 1st line and
unlock it when you exit. Otherwise, anything at anytime can be changed at any moment by any thread in that method.

For example, if you have a variable loaded with a value at the top of the method, that you then set a column to that variable while adding a row,

you

cannot just use System.Threading.Monitor.Enter(DataRowToAdd) to protect

the

row your are adding, because one of the variables might change by another thread. You would need to use System.Threading.Monitor.Enter on

everything

(variables, etc.) adding quite a bit of code. Even at that, I don't see
that System.Threading.Monitor.Enter stops another thread anyway.

I have spend a lot of time one this, and don't understand how to do it.

Can

you explain to me how to write a shared method that adds rows to a data

set,

and updates that dataset to the datasource, that can be used by multiple threads at the same time. Any URLs would be helpf ul to. Maybe if I

see a

working example, I will grasp what is going on.
The critical piece you're missing is that local variables don't need to be
protected. Each thread has it's own seperate stack, and the local

variables are on the stack.

Global variables, or Shared variables DO need to be protected. So if your
shared method doesn't reference any global or shared variables, then there's no need to use any syncronization.

So the question is "what objects are you sharing between threads", not "what methods". Then you must use appropriate serialization mechanisms to protect those shared objects.

Think about it, and post a more complete example, and perhaps someone can
suggest a strategy.

David

Thanks, that was helpful.

Then what is the difference between the following (where
gcCDsd.DS_Methods.Methods_Details is shared DataSet DataTabe).
Montior.Enter works (I have not tried running the program with Synclock).
SyncLock gcCDsd.DS_Methods.Methods_Details

Monitor.Enter(gcCDsd.DS_Methods.Methods_Details)

You can use monitor in a construct like the following that insures the
shared object is unlocked even if your code to modify the shared object
fails. You cannot do this with SyncLock.
try
Monitor.Enter(gcCDsd.DS_Methods.Methods_Details)
' SyncLock gcCDsd.DS_Methods.Methods_Details ***this does not work, End Synclock cannot be in finally
... code to modify gcCDsd.DS_Methods.Methods_Details
Finally
Monitor.Exit(gcCDsd.DS_Methods.Methods_Details)
' End SyncLock gcCDsd.DS_Methods.Methods_Details ***this does not work, End Synclock cannot be in finally.
end try

Thanks for all your help.
Bob Day