Yes, Adam, you are right. The example was derived (simplified) from my real
application. My class has a bunch of integer fields that get incremented
through various methods. I only have "get" properties for them, not because
I wanted them read-only, but because they are changed in bunches.
Anyway, I want to make sure that when a thread calls one method that changes
the fields, all other threads will be blocked if they try to read one value.
I could write the property like this:
public string MyField
{
get
{
string strTemp;
lock(this)
{
strTemp = strMyField_;
}
return strTemp;
}
}
But do I really have to?
-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] Behalf Of Adam Sills
Sent: Thursday, August 10, 2006 5:47 PM
To: [email protected]
Subject: Re: [ADVANCED-DOTNET] Multithread-safe classes
Well in this exact example, the effect is useless locking. Perhaps you have
a better example?
> -----Original Message-----
> From: Discussion of advanced .NET topics. [mailto:ADVANCED-
> [EMAIL PROTECTED] On Behalf Of Eddie Lascu
> Sent: Thursday, August 10, 2006 4:25 PM
> To: [email protected]
> Subject: [ADVANCED-DOTNET] Multithread-safe classes
>
> I want to make my class multithread safe. What's the effect of writing
> something like this:
>
> public sealed class MyClass
> {
> public MyClass(string strValue)
> {
> strMyField_ = strValue;
> }
>
> public string MyField
> {
> get
> {
> lock(this)
> {
> return strMyFieldId_;
> }
> }
> }
>
> string strMyField_;
> }
>
> I know "lock" injects the "finally" block into the CIL, but is that
> executed
> if the return is before?
===================================
This list is hosted by DevelopMentor. http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
