Synclock Questions

  • Thread starter Thread starter Bob Day
  • Start date Start date
B

Bob Day

Using vs 2003, vb.net sql msde..

Consider the following code snippets. See **** for questions. All are
shared and accessed by multiple threads simultaneiously.

' Instantiate per for this shared class

Private Shared gcCDsd As New Class_Component_Designer


Private 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 = "", Optional ByVal
Exception_Thrown_Message As String = "")

****** Question 0) The same as question 2 below for the arguments above.

... code to create row to add

SyncLock (gcCDsd.DS_Methods.Methods_Details)

' Add new DataRow to DataSet

gcCDsd.DS_Methods.Methods_Details.AddMethods_DetailsRow(DR_To_Add)

' Call method to update row to datasourse

Rows_Updated = DLsd.tblMETHODS_DETAILS_UPDATE()

End SyncLock

end sub



Private Shared Function tblMETHODS_DETAILS_UPDATE() As Integer

' Purpose: Updates the DataSource From the DataSet for this table only



****** Question 1) Since gcCDsd.DS_Methods.Methods_Details is synclocked in
the calling method, does it need to be synclocked again here. I think not,
since it would seem to be already locked. If so, it would seem that the
same thread running into the same item with a 2nd synclock on it would
ignore the 2nd synclock. Is that thinking correct?



' Holds Rows affected by DataAdapter commands, such as FILL or UPDATED

Dim Rows_Updated As Integer = -1

' call method to update datasource

Rows_Updated = DL.cmdUPDATE_DataSource(gcCDsd.DA_tblMethods_Details,
gcCDsd.DS_Methods.Methods_Details)

' return rows updated

Return Rows_Updated

End Function



Friend Shared Function cmdUPDATE_DataSource(ByVal SQL_Data_Adapter As
SqlDataAdapter, ByVal DataTable_To_Update As DataTable) As Integer

' Purpose: Updates any changes made to a dataset datatable to the
datasource



****** Question 2) Do the parameters passed above need to be synclocked?
In other words, if 2 threads call this, do the arguments above instantiate a
new variable each time it is called (like dim SQL_Data_Adapter As
SqlDataAdapter would) or do they amount to shared variables that must be
protected by synclocks? It worked with out synclocks with 2 threads, but as
I have added threads I have had problems.



' Holds number of DS rows Updated to DataSource

Dim Rows_Updated As Integer = -1



****** Question 3) You would never synclock the next DIM line, since each
pass by a different thread (even at the same time) would create its own
DT_With_Changes to work with.

' create DataTable to hold only the changes in table

Dim DT_With_Changes As New DataTable



' load with rows that have changes in table

DT_With_Changes = DataTable_To_Update.GetChanges()

Rows_Updated = SQL_Data_Adapter.Update(DT_With_Changes)

' all rows for this table set back to unmodified.

DataTable_To_Update.AcceptChanges()

' Return number of rows updated6

Return Rows_Updated

End Function


Thanks!

Bob Day
 
****** Question 1) Since gcCDsd.DS_Methods.Methods_Details is synclocked in
the calling method, does it need to be synclocked again here. I think not,
since it would seem to be already locked. If so, it would seem that the
same thread running into the same item with a 2nd synclock on it would
ignore the 2nd synclock. Is that thinking correct?
Click to expand...

You don't synclock variables, you synclock blocks of code.
Synclock establishes a walled gate around a piece of code and only allows
one thread through the gate at a time.
The variable that you use in the synclock is kind of like a ticket to get
through the gate, but there is (should be) only one ticket.
The first thread to come to the synclock statement "grabs" the ticket. The
bouncer at the front gate sees he has the ticket and lets him through. The
thread then gives up the ticket at the back gate (the end of the synclock
block). The second thread must wait in line until he can get his hands on
the ticket.
I would recommend creating a seperate variable used for locking.
****** Question 2) Do the parameters passed above need to be synclocked?
In other words, if 2 threads call this, do the arguments above instantiate a
new variable each time it is called (like dim SQL_Data_Adapter As
SqlDataAdapter would) or do they amount to shared variables that must be
protected by synclocks? It worked with out synclocks with 2 threads, but as
I have added threads I have had problems.
Click to expand...

All arguments get a seperate copy for each thread as they are placed on the
stack, and stacks are managed on a per-thread basis. However, what you have
as arguments here are object references (in essense pointers to some object
that lives on the heap). Getting multiple copies of pointers doesn't matter
because you are referencing the same objects on the heap, which might be
doing something at the time any particular thread is trying to use it.
Synclock this procudure to prevent that from happening (remember, you
synclocking code, not variables).
****** Question 3) You would never synclock the next DIM line, since each
pass by a different thread (even at the same time) would create its own
DT_With_Changes to work with.
Click to expand...

Once again, you synclock code, not variables :-)
However, you are right in saying that locally-scoped variables get created
unique to the current thread, so you don't need to worry about them, unless
they are references to a common object on the heap. In this case not,
because each thread is creating a NEW object.

-Rob Teixeira [MVP]
 
With all due respect, you are giving me to question 1 the exact opposite
answer I have been previously given in this newsgroup. Previous, it was
stated that you don't sysnclock code, you synclock shared or global
varialbles, modify them, end sycnlock , since those variables can be
modified by another thread.

You are saying create an arbitrary variable, and synclock all the code you
want (whether it pertains to shared or global variables or not), not
worrying about shared or global variables, like the follwing:

Private shared sub ToSomething
dim x as string
synclock x
..all code
end synclock
End Sub

Your approach seems easier, but by the vary nature of creating an arbitrary
variable to use synclock, that does not seem how synclock was intended to be
used.

Please advise. Also, can you provide soem URLs on your approach?

Thansk!
Bob
 
Back
Top