Reputation: 157
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
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
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
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