Question

I’ve stress tested the code below and it seems to work fine – what are the dangers of not locking in the simple case where there is a single thread writing and a separate thread reading a simple variable?

Have a class that has a public property…

Public Class PropHolder
    Private _myVar As Double
    Public Property myVar() As Double
        Get
            Return _myVar
        End Get
        Set(ByVal value As Double)
            _myVar = value
        End Set
    End Property
End Class

…and another which uses an instance of this class

Public Class Form1 

Public _propHolder As New PropHolder
Delegate Sub dlgPostVar()

    Private Sub BackgroundWorker1_DoWork(ByVal sender As System.Object, ByVal e As System.ComponentModel.DoWorkEventArgs) Handles BackgroundWorker1.DoWork
        While Not BackgroundWorker1.CancellationPending
            _propHolder.myVar = someValue  'worker thread writing var
        End While
    End Sub

    Private Sub BackgroundWorker2_DoWork(ByVal sender As System.Object, ByVal e As System.ComponentModel.DoWorkEventArgs) Handles BackgroundWorker2.DoWork
        While Not BackgroundWorker2.CancellationPending
            Me.Invoke(New dlgPostVar(AddressOf postVal)) 'invoke UI thread to write var
        End While
    End Sub

    Private Sub postVal()
        RichTextBox1.AppendText(_propHolder.myVar.ToString & vbCrLf)
    End Sub

End Class

In the above example myVar is continuously changing and being written to a RichTextBox as fast as the UI can keep up. Not all of the values are captured but this is not important – let’s imagine that the RichTextBox only cares about sampling the current value of myVar at its leisure.

Everything I have read leads me to believe that this is not safe to do but I have yet to make it fail, even when having two threads reading and writing (single reader, single writer) this variable incessantly. What can go wrong here, and why?

Edit : To be more specific, this question is more hypothetical than practical. I know that this situation requires a lock “by the book”, the question is exploring the breadth of potential consquences of not locking in this instance, hopefully in the form of a complete collection of all potential modes of failure.

One example thusfar is a read from a variable being written to :

• Thread 1 -> Reads low word from memory
• Thread 2 -> CPU moves low word of new value to memory
• Thread 2 -> CPU moves high word of new value to memory
• Thread 1 -> Reads high word from memory

Thread 1 Value is now (HighWord[new])(LowWord[old]) ** corrupt

Program failure is limited to damage caused by processing of this corrupt value.
Other consequences of this failure mode? Are there any?

Further examples? Books/references welcome.

Edit #2 : My intention here is to explore, in the .NET framework, the extent and form of unpredictability and errors which are intrinsic to the platform and specifically not related to the consequences of how any specific program might subsequently fail in the face of such an error.

In the example above, I am doing nothing with a value aside from writing it out as text. If I get a bad value, I write a bad value to text – nothing explodes, the program does not crash, empires do not fall, and the orbit of Mercury remains stable.

Answer 1

You do need a lock in this case as variable writes to double are not atomic. Therefore, it is possible for this to break, just extremely unlikely.