Synlock Q - Subprocedure with same object lock

[Spam Catcher]

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

[Spam Catcher]

"Robin Tucker" <rt******@hotmail.comwrote in
news:f3*******************@news.demon.co.uk:

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]

On May 30, 8:52 am, Spam Catcher <[e-mail]:

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.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

"Spam Catcher" <sp**********@rogers.comwrote in message
news:Xn**********************************@127.0.0. 1...

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.

[Spam Catcher]

"Chris Mullins [MVP]" <cm******@yahoo.comwrote in
news:O2**************@TK2MSFTNGP05.phx.gbl:

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.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

"Spam Catcher" <sp**********@rogers.comwrote in message
news:Xn*********************************@127.0.0.1 ...

"Chris Mullins [MVP]" <cm******@yahoo.comwrote in
news:O2**************@TK2MSFTNGP05.phx.gbl:

>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?

[Spam Catcher]

"Chris Mullins [MVP]" <cm******@yahoo.comwrote in
news:#K**************@TK2MSFTNGP06.phx.gbl:

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