Question

In the following example GetList returns an instance of a static (shared) variable. That one needs locking in order to be thread-safe.

But what about DoSomething which doesn’t use any static variables outside the method? Does it need locking too?

EDIT: I’d like to clarify that in this particular case I expect DoSomething to always print 0-100 in sequence (i.e. no 0123745…) regardless of number of calling threads. Or, in general, that different threads don’t affect each other’s variables (printing to console is only an example). The language in the following example is VB.NET.

As paxdiablo said:

In this case, it appears the only thing touched is the local variable
i which would have a separate copy for every function invocation.
In other words, it wouldn’t need protecting.

That is exactly what I was trying to solve. Thank you!

Public Class TestClass

    Private Shared lock As New Object
    Private Shared list As List(Of Integer)

    Public Shared Function GetList() As List(Of Integer)

        SyncLock lock
            If list Is Nothing Then
                list = New List(Of Integer)
            End If
            Return list
        End SyncLock

    End Function

    Public Shared Sub DoSomething()

        Dim i As Integer

        For i = 0 To 100
            Console.WriteLine(i.ToString)
        Next

    End Sub

End Class

Answer 1

Well, that would mostly depend on the language which you haven’t specified but, generally, if code doesn’t touch a resource that another thread can also touch, it doesn’t have to be protected.

In this case, it appears the only thing touched is the local variable i which would have a separate copy for every function invocation. In other words, it wouldn’t need protecting.

Of course, it could be argued that the console is also a resource and may need protection if, for example, you didn’t want lines interfering with each other (synclock the write) or wanted the entire hundred lines output as a single unit (synclock the entire for loop).

But that won’t really protect the console, just the block of code here that uses it. Other threads will still be able to write to the console by not using this method.

Bottom line, I don’t think you need a synclock in the second method.

---

This section below is not relevant if you’re using SyncLock in VB.Net (as now seems to be the case). The language guarantees that the lock is released no matter how you leave the block. I’ll leave it in for hysterical purposes.

I’d be a little concerned about your synclock placement in the first method, especially if the return statement was a transfer of control back to the caller (and the synclock didn’t automatically unlock on scope change). This looks like you can return without unlocking, which would be a disaster. I would think the following would be more suitable:

Public Shared Function GetList() As List(Of Integer)
    SyncLock lock
        If list Is Nothing Then
            list = New List(Of Integer)
        End If
    End SyncLock
    Return list
End Function