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