Multiple threads accessing Shared functions

[Bob Day]

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

 

[CJ Taylor]

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

 

[David Browne]

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

 

[David Browne]

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]

Obviously you missed the part of the post where he said he didn't want to
use Synclock....

 

[Bob Day]

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

Friend Shared Sub Write

SyncLock Me

' code

End SyncLock

end sub

because Me is invalid and Synclok expects an expression. Is there an
alternative expression?

IF I try using it to call the above shared, something like:

SyncLock DLsd.Write

End SyncLock

I get an error that the Write does not produce a value.

So, I don't see how to use Synclock except in limited situations where the
method returns a value.

Please advise.

Bob Day

 

[David Browne]

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]

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

 

[Bob Day]

That was very helpful, thanks.
Bob Day

see


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

 

[David Browne]

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

SyncLock is a convenience feature that saves you from having to use a
finally block to leave the Monitor.

SyncLock o
'do something
end SyncLock

Is compiled as

Monitor.Enter(o)
try
'do something
finally
Monitor.Exit(o)
end try


So puting "end SyncLock" in a finally block is redundant.

David