Question

I have the following code in a class that manages refreshing some object automatically that also allows you to manually refresh. I want to make it thread-safe.

Public Function ForceRefresh() As Foo
  DoRefresh()
  ResetTimer()
  Return Me.CurrentFoo
End Function

Private Sub DoRefresh()
  Me._currentFoo = Me._retriever.GetTheFoo()
End Sub

I’m tempted to Synclock both of these methods:

• ForceRefresh: So we don’t get multiple consumer threads trying to force a refresh and reset the timer at the same time
• DoRefresh: So we don’t try to GetTheFoo() if we’re already in the middle of trying to retrieve one. I’m using System.Threading.Timer which might call back on any of the ThreadPool threads, so simply using a flag might not be appropriate (but maybe is still necessary?)

… like this:

Private _syncRoot As New Object

Public Function ForceRefresh() As Foo
  Synclock _syncRoot
    'Snip ...
  End Synclock
End Function

Private Sub DoRefresh()
  Synclock _syncRoot
    'Snip ...
  End Synclock
End Sub

But then I end up trying to Synclock on _syncRoot twice when calling ForceRefresh… now if Synclock is reentrant then nesting these won’t be an issue. The MSDN documentation page seems to imply that this is the case, but doesn’t say it explicitly.

Note: I’m gonna give this a try myself, but I didn’t see anything about this on StackOverflow and thought it was an useful question to have answered.

Answer 1

The SyncLock statement uses Monitor.Enter() under the hood. The MSDN library says:

It is legal for the same thread to invoke Enter more than once without it blocking

Which means it is re-entrant. Easy to check btw.