3

I presently write C# WPF application. I'm in need of synchronous access for read/write to a variable from three threads. This variable is declared as the member of the application main window class. So I declared it in the following way:

public partial class MainWindow : Window
{
    . . . . .
    #region Fields
    /// <summary>
    /// The variable myVar to synchronous access for read/write. 
    /// </summary>
    private static Double myVar;
    #endregion
    . . . . .
}

Can I provide the synchronous access to it in the following way:

1) Define the synchronization object as the member of MainWindow class

public partial class MainWindow : Window
{
    . . . . .
    #region Fields
    /// <summary>
    /// This object is controlling the synchronous access for read/write to myVar. 
    /// </summary>
    private static Object syncObj;
    #endregion
    . . . . .
}

2) Define the next property in the MainWindow class

public partial class MainWindow : Window
{
    . . . . .
    #region Properties
    /// <summary>
    /// This property supports synchronous access to myVar for read/write. 
    /// </summary>
    public static Double MyVar
    {
        lock(syncObj)
        {
            get{ return myVar; }
            set{ if(myVar != value) myVar = value; }
        }
    } 
    #endregion
    . . . . .
}

Will this property work in the right way? Will it ensure sure method of synchronous access for read/write to myVar variable? I don't want to use volatile or methods as Thread.VolatileRead and Thread.VolatileWrite because many people say that lock operator works better and allow to compiler to optimize code.

rekire
  • 47,260
  • 30
  • 167
  • 264
user1688773
  • 157
  • 1
  • 3
  • 11
  • Search for "C# memory fence" (or "barrier") for some interesting reads (and leads to http://stackoverflow.com/questions/6581848/memory-barrier-generators and similar) –  Sep 28 '12 at 06:13

3 Answers3

1

This seems absolutely fine to as, as long as the Main window does not reference the private variable itself, but rather the propert.

From lock Statement (C# Reference)

The lock keyword marks a statement block as a critical section by obtaining the mutual-exclusion lock for a given object, executing a statement, and then releasing the lock.

The lock keyword ensures that one thread does not enter a critical section of code while another thread is in the critical section. If another thread tries to enter a locked code, it will wait, block, until the object is released.

Another interesting option to look at might be ReaderWriterLockSlim Class

Represents a lock that is used to manage access to a resource, allowing multiple threads for reading or exclusive access for writing

Adriaan Stander
  • 162,879
  • 31
  • 289
  • 284
  • So I can use the MyVar property for synchronous access for read/write to myVar variable from the threads and synchronization will be excellent ? – user1688773 Sep 28 '12 at 06:10
  • A critical section is only part of what is required; thankfully `lock` also has memory barrier guarantees .. –  Sep 28 '12 at 06:16
0

I think there is nothing wrong with your approach as one of StackOverflow user sad. Personally I would also suggest u to have a look at ReaderWriterLockSlim Class as it seems really interesting relative to synchronization process during code execution. Just follow those rules

lock (this) is a problem if the instance can be accessed publicly.

lock (typeof (MyType)) is a problem if MyType is publicly accessible.

lock("myLock") is a problem because any other code in the process using the same string, will share the same lock.
Rati_Ge
  • 1,262
  • 2
  • 15
  • 37
0

Your way will work, but you can get better performance using Interlocked.CompareExchange method: http://msdn.microsoft.com/en-us/library/cd0811yf.aspx

Shahar Gvirtz
  • 2,418
  • 1
  • 14
  • 17