SyncLock - ByRef vs. ByVal

[Guest]

Hello all,

If I pass in a parameter using ByRef, is there a difference in the way
Synclock behaves? Will synclock obtain an exlcusive lock on a referenced
object?

Or... does Synclock only work well with parmaeters passed ByVal?

 

[Mattias Sjögren]

If I pass in a parameter using ByRef, is there a difference in the way
Synclock behaves?

No


Mattias

 

[Guest]

No

So with a reference... synclock is able to lock the object? What if
multiple classes have references to the same object?

Just confirming.

 

[Herfried K. Wagner [MVP]]

So with a reference... synclock is able to lock the object? What if
multiple classes have references to the same object?

Well, that's the reason 'SyncLock' works. It doesn't matter whether or not
the reference has been passed 'ByRef' or 'ByVal', because in both cases the
same object is being used as lock object. Locking only works with reference
types (classes, modules, etc.) but not with value types!

 

[Ian]

No

I'm guessing, do you work for vodafone customer service?

 

[Guest]

Well, that's the reason 'SyncLock' works. It doesn't matter whether
or not the reference has been passed 'ByRef' or 'ByVal', because in
both cases the same object is being used as lock object. Locking only
works with reference types (classes, modules, etc.) but not with value
types!

Thanks for clarifying : )

 

[Guest]

If I understand you correctly, then if I have a value type variable in my
module from which I start a thread that access the value type variable,
synclock won't work on the value type variable and both the thread and module
procedures can access the variable at the same time?

 

[Herfried K. Wagner [MVP]]

If I understand you correctly, then if I have a value type variable in my
module from which I start a thread that access the value type variable,
synclock won't work on the value type variable and both the thread and
module
procedures can access the variable at the same time?

The compiler prevents you from locking on a variable which has a value type.

 

[branco.medeiros]

If I understand you correctly, then if I have a value type variable in my
module from which I start a thread that access the value type variable,
synclock won't work on the value type variable and both the thread and module
procedures can access the variable at the same time?

No, you're misunderstanding the use of SyncLock. VB won't even compile
a SyncLock to a value type.

What SyncLock does is to keep threads waiting for a given "lock", as
long as that "lock" is in use. It does nothing to prevent different
threads from acessing this or that variable.

In other words, it's like if your thread locked itself into a closet
where no other thread can enter because only it (the thread) has the
key. All will go well if every thread wait for the key to enter the
closet. But if any of your threads pretend that they're Neo and realize
that "there's no closet", then all sorts of weird things may happen.

So, you *will* use SyncLock to prevent simultaneous access to a given
variable (or group of variables) if you only access the variable(s)
when you (the thread) have the lock.

It turns out that the lock must be a reference-type variable.

Ex:
Private mLock As New Object
Private Structure Info
Name As String
Age As integer
End Structure

Private mValue As Info

'...
Sub DoThis
'...
SyncLock mLock
mValue.Name = "Carlos"
mValue.Age = 15
End SyncLock
'...
End Sub

Sub DoThat
'...
SyncLock mLock
mValue.Name = "Rita"
mValue.Age = 42
End SyncLock
'...
End Sub

Sub DoBlah
'...
Dim Value As Info = mValue
'...
End Sub

If you have a thread running on DoThis and another on DoThat, and they
both ask for the same lock (mLock, in the example) to access mValue,
then you're guaranteed that the value of mValue will be consisitent. On
the other hand, if you break this protocol (as DoBlah does), of not
using the same lock when accessing variables shared by different
threads, then you lose all guarantees of integrity (in this case, the
mValue seen by DoBlah may be completely inconsistent).

To preserve the integrity, all points of your code that may be running
in separate threads must keep the protocol: only access a given set of
variables after acquiring the pertinent lock.

Ex:

Sub DoBlah
'...
Dim Value As Info
SyncLock mLock 'Now I may do whatever I want
Value = mValue
End SyncLock
'...
End Sub

Hope this helped.

Regards,

Branco.

 

[Guest]

I understand synclock and how to use it...I just didn't realize it couldn't
be used on a value type variable. How do you prevent the main thread and
another thread from simultaneously accessing a value type variable

 

[Branco Medeiros]

I understand synclock and how to use it...I just didn't realize it couldn't
be used on a value type variable. How do you prevent the main thread and
another thread from simultaneously accessing a value type variable

<snip>

I'm afraid to say that your very question reveals your misunderstanding
of the way synclock works.

To prevent access to a given variable, it's required that you only
access such variable after having acquired a common lock (which has
nothing to do with the variable being accessed).

Other than that, there's nothing that could prevent unwanted access. It
really depends on your discipline to keep the "protocol".

What it seems to me is that you're assuming that taking a variable as a
lock will prevent access to *that* variable. If so, then your
assumption is wrong. The lock is used just as a 'token', a ticket, a
key.

Notice that even if you acquire a lock on a given variable, any thread
that doesn't acquire the same lock still has free access to that very
variable that you'd seem to be 'locking'. Alas, acquiring a lock on a
variable does nothing to prevent access to the variable used as lock.

Why do you use a variable as lock, then? Because, to keep the
"protocol" of just accessing some set of variables after acquiring a
given lock, it's obvious that the variable used as lock must be a
common variable to all the threads participating in the concurrent
actions that you want to synchronize. This variable is usually the
object itself where the 'action' takes place, although it doesn't need
to be so. The lock may be any common reference type variable that all
participant threads can grab.

HTH.

Regards,

Branco.