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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With