Synlock Q - Subprocedure with same object lock

  • Thread starter Thread starter Guest
  • Start date Start date
G

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.
 
Hi,


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


Robin
 
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.
Click to expand...

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.
 
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.
 
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.
Click to expand...

Is there a better pattern? Basically A uses B's code. B is sometimes called
on it's own as well?
 
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.
 
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
Click to expand...

That's for that one :-) Neat trick.
 
Back
Top