Develop Reference

Does a simple property need synchronization? [duplicate]

I would like to know if C# automatically implemented properties, like public static T Prop { get; set; }, are thread-safe or not. Thanks!

Section 10.7.4 of the C# specification states:
When a property is specified as an
automatically implemented property, a
hidden backing field is automatically
available for the property, and the
accessors are implemented to read from
and write to that backing field. The
following example:
public class Point {
public int X { get; set; } // automatically implemented
public int Y { get; set; } // automatically implemented
}
is equivalent to the following declaration:
public class Point {
private int x;
private int y;
public int X { get { return x; } set { x = value; } }
public int Y { get { return y; } set { y = value; } }
}
That's what we promise, and that's what you get. The point of auto properties is to do the most basic, simple, cheap thing; if you want to do something fancier then you should write a "real" property.

It appears not. This is the decompilation with Reflector:
private static string Test
{
[CompilerGenerated]
get
{
return <Test>k__BackingField;
}
[CompilerGenerated]
set
{
<Test>k__BackingField = value;
}
}

No. You must wrap them in thread-locking mechanisms.
object _lock = new object();
public static Main(string[] args)
{
lock(_lock)
{
Prop = new T();
}
T val = null;
lock(_lock)
{
val = Prop;
}
}

There is no synchronization provided with automatic properties, including static properties.
If you need full thread safety, you'll want to use your own properties with a backing field, and handle the synchronization yourself.

For completeness, field-like events do have thread-safety built in, but they are alone in this. Automatically implemented properties do not have any such features. You can, however, do something like:
public static double SomeProp
{ // ### NOT RECOMMENDED ###
[MethodImpl(MethodImplOptions.Synchronized)] get;
[MethodImpl(MethodImplOptions.Synchronized)] set;
}
The problem with this is that it will lock the Type, which is a bad thing. I would implement my own synchronization for this, personally.

I don't believe so. I believe they are just syntatic sugar for:
private static T _prop;
public static T Prop
{
get { return _prop; }
set { _prop = value; }
}

No, they not threadsafe. Static properties just as vulnerable as static fields are to concurrency issues.

Declaring properties properly

For some reason since the last Visual Studio 2015 update, my code crashes with a StackOverflow when running my reports from Grape City ActiveReports. It seems to crash when I am setting properties on the report. The question is which is the best way to define properties?
I want to send a some value to my class objects like:
MyClass clsObj = new MyClass();
clsObj.MyProperty = 1;
This is what I do now as a sample:
public class MyClass() {
public int MyProperty;
}
But if you use the shortcut for prop and press tab you get this:
public class MyClass() {
public int MyProperty { get; set; }
}
I then see where people do this:
public class MyClass() {
private int _MyProperty;
public int MyProperty { get { return _MyProperty; } set {_MyProperty = value; } }
}
Which is the best practice?

It all depends on how you want to use your properties.
The usual way properties are written is like so:
public int MyProperty { get; set; }
The code above is the same as writing this:
public int MyProperty { get { return _MyProperty; } set {_MyProperty = value; } }
you don't need the extra backing field unless you want to perform some other logic within the properties getter and setter.
in C# 6.0 you can now do property initializers like this:
public DateTime TimeStamp { get; } = DateTime.UtcNow;
You can use that instead of initializing the property in a constructor of a class.
As for your code not working, I can't really tell, you haven't posted enough information.
Microsoft have a lot of information on c# 6.0 properties here:
https://msdn.microsoft.com/en-us/magazine/dn802602.aspx

What's the difference between a property with a private setter and a property with no setter?

If I want a read-only property, I write it like:
public int MyProperty { get { //Code goes here } }
However, the Microsoft example (and a few other examples I've seen) are written like:
public int MyProperty { get; private set; }
Is there any difference between these two, and should I start writing properties like this?

As you can see in your second sample, you can leave out the implementation for a property. .NET will then automatically create a local variable for the property and implement simple getting and setting.
public int MyProperty { get; private set; }
is actually equivalent to
private int _myProperty;
public int MyProperty {
get { return _myProperty; }
private set { _myProperty = value; }
}
Writing
public int MyProperty { get; }
does not work at all, as automatic properties need to implement a getter and a setter, while
public int MyProperty { get; private set; }
leaves you with a property that may return any int, but can only be changed within the current class.
public int MyProperty { get { ... } }
creates a read-only property.
Question is: what do you need? If you already have a member variable that's used within your class and you only want to return the current value using a property, you're perfectly fine with
public int MyProperty { get { return ...; }}
However, if you want a read-only property, which you need to set within your code (but not from other classes) without explicitly declaring a member variable, you have to go with the private set approach.

With private setter you can only assign property value inside of instance when property is without setter you can't set its value anywhere.

If you don't use an explicit member assignment in the property, you'll have to declare a private set at least in order to be able to set a value to this property. Otherwise, you'll get a warning at compile-time saying that your property cannot be assigned.
If you use an explicit member, you'll be able to assign a value to this member directly, without needing to add a private set:
private int member ;
public int MyProperty {
get { return member; }
}
// ...
member = 2;
int anotherVariable = MyProperty; // anotherVariable == 2

public int MyProperty
{
get
{
// Your own logic, like lazy loading
return _myProperty ?? (_myProperty = GetMyProperty());
}
}
A property with only a getter is very useful if you need your own logic behind the access of that property, in particular when you need the property to be lazy loaded.
public int MyProperty { get; private set; }
A property with a private setter is useful if you need the property not te be changed from the outside, but still maintained from within the class.
In both cases, you can have a backing data field for the actual value, but in the former, you'll have to maintain that yourself, and in the latter, it is maintained for you by the generated code.

There is a difference when you access the object with reflection.
public class Foo
{
public string Bar { get; private set; }
}
// .....
internal static void Main()
{
Foo foo = new Foo();
foo.GetType().GetProperty("Bar").SetValue(foo, "private?", null);
Console.WriteLine(foo.Bar);
}

How to make a property set itself using {} instead of ;?

Here is an interesting tidbit where I could not really find on the interwebs. The idea is that if you have a property such as int a { get; set; } it could set itself.
How do you make the property set itself with int a { get { } set { } }?
What is happening inside of set;?
Here is what I tried to do:
public string Symbol { get { return Symbol; } set { Symbol = value; NotifyPropertyChangedEvent("Symbol"); } }
But it obviously creates a Stack Overflow because it is essentially calling itself over and over.
And I don't want to create 10-20 private variables to work along side of my properties, I want to know what is happening in set;.
Thank you.

set; just creates a private variable that you can't see. You'll need those 10-20 private variables, sorry.

You have to create private variables.
Unfortunately, that's the only way in the specific circumstance you have here.

If you need custom logic, you'll need to provide the backing field yourself:
private string symbol;
public string Symbol
{
get { return symbol; }
set { symbol = value; NotifyPropertyChangedEvent("Symbol"); }
}
And I don't want to create 10-20 private variables to work along side of my properties, I want to know what is happening in set;.
With an automaticaly property (ie: public string Symbol { get; set; }), the compiler creates the backing field automatically. However, there is no way to introduce logic (ie: raise your event) without managing the backing field(s) yourself.

It generates a backing field for you when it gets compiled. You cannot access it via intellisense because it has not been created yet. It is equivalent to the following where '_a' has not been generated yet.
private int _a;
public int a
{
get { return _a; }
set { _a = value; }
}
You could, however, simply set the property itself from inside of your class.
public int a { get; set; }
a = ...;
Additionally, you can set modifiers on the get and set if you only want to be able to set it internally;
public int a { get; private set; }

How do you keep your backing fields organized? (Styles/Patterns)

c# 3.0 offers us getters and setters with compiler generated backing fields - this is really great, but there are plenty of times that you still need to use a backing field.
In a perfect world (opinion), you would be able to do something like
class MyClass {
... stuff ...
public string MyProperty {
private string _myBackingField = "Foo";
get { return _myBackingField; }
set { _myBackingField = value; }
}
}
instead of
class MyClass {
private string _myBackingField = "Foo";
... stuff ...
public string MyProperty {
get { return _myBackingField; }
set { _myBackingField = value; }
}
}
Does anyone have suggestions or techniques which come close to this? Or to put it another way - what is the clearest way to keep your backing fields and properties organized.

I still prefer
class MyClass {
private string _myBackingField = "Foo";
private string _myOtherBackingField = "bar";
... stuff ...
public string MyProperty {
get { return _myBackingField; }
set { _myBackingField = value; }
}
public string MyOtherProperty {
get { return _myOtherBackingField; }
set { _myOtherBackingField = value; }
}
}
If the lack of proximity bothers you, you can put the backing field for each property above the property it services.
class MyClass {
private string _myBackingField = "Foo";
public string MyProperty {
get { return _myBackingField; }
set { _myBackingField = value; }
}
private string _myOtherBackingField = "bar";
public string MyOtherProperty {
get { return _myOtherBackingField; }
set { _myOtherBackingField = value; }
}
}

I tend to keep the backing fields together at the top, but then I do that with method variables too. Perhaps its a carry over from some of the older languages where variable declaration was always the first step, but it just seems more organized to me than declaring variables inline as needed.
If you don't like declaring variables at the top, the closest I've seen to your "ideal" style would be:
private int _integer1 = 0;
public int Integer1
{
get {return _integer1;}
set {_integer1 = value;}
}

What I prefer:
public int Integer1
{
get {return _integer1;}
set {_integer1 = value;}
}
private int _integer1 = 0;
Why?
because the property is much more
important than the backing field so
it should be read as the first.
if you comment your property, what reads nicer?
this
private int _integer1 = 0;
///<summary>
/// this is my property, enjoy it
///</summary>
public int Integer1
{
get {return _integer1;}
set {_integer1 = value;}
}
or
///<summary>
/// this is my property, enjoy it
///</summary>
public int Integer1
{
get {return _integer1;}
set {_integer1 = value;}
}
private int _integer1 = 0;
The approchach with the backing field at the end is much more readable imho. The same holds for applying attributes to the property.

Why would you put "...stuff..." between the property and the field? I'm a firm believer in keeping tightly-coupled things as close as possible:
class MyClass {
... stuff ...
private string _myBackingField = "Foo";
public string MyProperty {
get { return _myBackingField; }
set { _myBackingField = value; }
}
}
I would also not introduce an extra field unless I had to:
because I need logic the in accessors
for (BinaryFormatter) serialization reasons
In the example given, I'd just use an auto prop:
class MyClass {
... stuff ...
public MyClass() {
MyProperty = "Foo";
}
[DefaultValue("Foo")]
public string MyProperty { get;set; }
}
Obviously, some kind of auto-prop syntax that allowed a default would be nice here, but I don't need it, so I don't expect it any time soon. It doesn't solve a big enough problem to be worth much effort...

I agree that the OP's "perfect world" example would be useful. An auto-property wouldn't work for a lazy-loading scenario:
class MyClass
{
... stuff ...
public string MyProperty
{
private string _myBackingField;
get
{
if (_myBackingField == null)
{
myBackingField = ... load field ...;
}
return _myBackingField;
}
set { _myBackingField = value; }
}
}
In fact I raised this as a suggestion on Microsoft Connect some time ago.

In practice, it doesn't seem to matter.
In my experience, once a class passes a certain threshold of complexity (which is basically the threshold between "trivial" and "non-trivial"), I no longer navigate through the class by scrolling around in its source, I navigate by using Go To Definition and Find Usages.
Using linear proximity to imply things about relationships between class members seems like a good idea, but I think it really isn't. If I see this:
private string _Foo;
public string Foo
{
// arbitrarily complex get/set logic
}
the implication is clear: _Foo is used only by the Foo property. That implication's not dependable, though. The only way for me to be certain that there's no code in the class that's manipulating _Foo is to inspect it. Well, if I can't rely on proximity to tell me anything, why should I care about proximity at all?
These days, I just alphabetize my class members from the start. This frees me up from having to think about something (where should I put this member, and why should I choose that place for it?) that doesn't really matter.