CodeHulk

I'm just kind of curious on this. I wasn't sure how to test it on my own as it is a threading issue and not reliable. Consider the following example.

Code Snippet

private object LOCK = new object();

private bool _Foo;

private bool Foo

{

get

{lock(LOCK){return _Foo}}

set

{lock(LOCK){_Foo = value;}}

}

Will this code ensure that is long as I use Foo instead of _Foo I shouldn't have to worry about any concurrency issues with _Foo

Thanks

~Justin



Re: Visual C# General Thread Lock Question

OmegaMan

Off the bat, you are locking a value type which gets copied on return of the getter. The setting and extracting are safe for _foo...but if your intention is does the lock remain if someone is using the Foo after doing a get, the answer is no.

For the lock is only local that scope and once the item is extracted the lock is off. The lock is just a convenient way to say (this is a simplified example there is more too it)

Moniter.Enter(lockobj);

.... the code

Moniter.Exit(lockobj);

Once exit is hit it is turned off. See this article Threading in C# which is a good place to learn about the concepts.







Re: Visual C# General Thread Lock Question

Peter Ritchie

OmegaMan wrote:
Off the bat, you are locking a value type which gets copied on return of the getter. The setting and extracting are safe for _foo...but if your intention is does the lock remain if someone is using the Foo after doing a get, the answer is no.
LOCK is not a value type. Or, do you mean the synchronized access to _Foo

Reference assignments and built-in type assignments are guarenteed in the C# spec to be atomic; there's no need to synchronize them (you're simply adding overhead that isn't being used).

If you've got an invariant that you need to protect (i.e. you shouldn't set Foo during some other state), then you need to address that outside of the Foo property.






Re: Visual C# General Thread Lock Question

OmegaMan

Peter Ritchie wrote:
LOCK is not a value type. Or, do you mean the synchronized access to _Foo;


Value type in that _Foo is a value type which is being returned in the user's code.

Peter Ritchie wrote:

Reference assignments and built-in type assignments are guarenteed in the C# spec to be atomic; there's no need to synchronize them (you're simply adding overhead that isn't being used).



That is something that I overlooked in my response. The lock on such a type is superfluous due to its atomicity.

Thanks Peter! From here on out I will be aware to present that fact in any future posts I do on the subject.





Re: Visual C# General Thread Lock Question

OmegaMan

Also I would add that _foo should be tagged volitile hence eliminating the need for lock as well...





Re: Visual C# General Thread Lock Question

Peter Ritchie

The volatile keyword ensures that read/writes to a variable are done without being optimized to a register or temporary memory. While it's good practice to mark members as volatile that may be accessed by multiple threads; if the member is only ever accessed via the property set/get (as in the sample) and the set/get implementations have no need to cache the value of _foo (the sample code has no need to cache the value) then volatile won't have any affect.