Synlock Q - Subprocedure with same object lock

[Guest]

Hi All,

If I have a procedure that obtains a sync lock:

Public Sub A
SyncLock Myobject
B()
End SyncLock

And another procedure which obtains the same synclock:

Public Sub B
SyncLock Myobject
... Do Stuff
End SyncLock

Will this cause a deadlock? Since A calls B - will the synclock be granted
to the subprocedure call?

Thanks.

 

[Robin Tucker]

Hi,


It will have no effect as both calls happen on the same thread. Your thread
already holds the lock.


Robin

 

[Guest]

Hi,


It will have no effect as both calls happen on the same thread. Your
thread already holds the lock.

Ah OK - good to know.

Thanks.

 

[Brian Gideon]

Hi All,

If I have a procedure that obtains a sync lock:

Public Sub A
SyncLock Myobject
B()
End SyncLock

And another procedure which obtains the same synclock:

Public Sub B
SyncLock Myobject
... Do Stuff
End SyncLock

Will this cause a deadlock? Since A calls B - will the synclock be granted
to the subprocedure call?

Thanks.

It will not cause a deadlock. The same thread is allowed to
recursively enter the same monitor. Just remember that the number of
Monitor.Enter and Monitor.Exit calls must match. That's pretty much a
given since you're using SyncLock.

 

[Chris Mullins [MVP]]

It'll work, but it's a really bad idea. It works because Montiors - which
are the framework component under SyncLock - are reenterant.

Although it'll work, there are many pitfalls and deadlocks ahead of you,
along with a number of poorly concluded late-night debugging sessions...

If there's any way you can change your design to avoid this pattern, you
really should.

 

[Guest]

It'll work, but it's a really bad idea. It works because Montiors -
which are the framework component under SyncLock - are reenterant.

Although it'll work, there are many pitfalls and deadlocks ahead of
you, along with a number of poorly concluded late-night debugging
sessions...

If there's any way you can change your design to avoid this pattern,
you really should.

Is there a better pattern? Basically A uses B's code. B is sometimes called
on it's own as well?

 

[Chris Mullins [MVP]]

Without seeing what exactly you're doing, it's hard to say.

I can say that I've built a number of complex and highly concurrent
applications, and it's very, very, very rare that I end up re-entering a
lock. This is something did when I was first learning, and it bit me so
hard, so many times, that I know avoid it at (almost) all costs.

You want to lock as little as possible (but no less!), for as short a time
as possible. Sometimes this means doing:

Dim temp as new List(Of String);
synclock(mylock)
For Each s as string in _myImportantCollection
if s.StartWith("s") then temp.Add(s)
Next
end lock

' ... now perform operations on the temp collection.
' Notice that we're outside the lock...

There are all sorts of tricks. Encapsulation is really important - keep your
locks scoped at the right level, and directly relevant to the class at hand.

 

[Guest]

You want to lock as little as possible (but no less!), for as short a
time as possible. Sometimes this means doing:

Dim temp as new List(Of String);
synclock(mylock)
For Each s as string in _myImportantCollection
if s.StartWith("s") then temp.Add(s)
Next
end lock

That's for that one Neat trick.