user1688773
user1688773

Reputation: 157

Can I use C# lock operator inside the property to synchronize access to read/write to a variable?

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.

Upvotes: 3

Views: 2015

Answers (3)

Shahar Gvirtz
Shahar Gvirtz

Reputation: 2438

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

Upvotes: 0

Rati_Ge
Rati_Ge

Reputation: 1270

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.

Upvotes: 0

Adriaan Stander
Adriaan Stander

Reputation: 166406

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

Upvotes: 1

Related Questions