To lock or not?

[fritzcwdev]

I have a class as follows:

public class OperationFeedba ck
{
DateTime _startTime;

public DateTime StartTime
{
get
{
return _startTime;
}
set
{
_startTime = value;
}
}

}

Set will occur in a background thread. Getting will occur from my GUI
thread. Should I implement a lock inside the get and set? If I so why?

Thanks,

- Fritz

[Nicholas Paldino [.NET/C# MVP]]

Fritz,

If the StartTime property is the only one item that you need to
synchronize, then I would say in the class is fine. However, as a general
guideline, I think that there are few classes that should do this (even this
one). The reason for this is that operations are usually more complex than
simple get/sets, and you really should be wrapping those entire operations
in lock blocks to make sure that the whole operation is synchronized, not
just one part of it.

Of course, if you encapsulate your operations well enough, you can
synchronize access to those in a class.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

<fr********@gma il.comwrote in message
news:13******** *************** ***********@i12 g2000prf.google groups.com...

>I have a class as follows:

public class OperationFeedba ck
{
DateTime _startTime;

public DateTime StartTime
{
get
{
return _startTime;
}
set
{
_startTime = value;
}
}

}

Set will occur in a background thread. Getting will occur from my GUI
thread. Should I implement a lock inside the get and set? If I so why?

Thanks,

- Fritz

[Fritz]

If I leave the class as is? Is it possible that when the "get" is
called from one thread in the middle of the "set" from another, that
the value could contain part of the old and part of the new value
(since DateTime is not atomic). If I want to ensure a proper value
when I "get", I suspect I need to lock (this is what I am trying to
confirm / understand).

- Fritz

[Rene]

the value could contain part of the old and part of the new value

So are you saying that you are worried about having a stored value of say
"3/3/2003 3:33 PM" and then having the set method called to set a new value
of say "5/5/2005 5:55 AM" and during this process call the get method and
end up reading something like "5/5/2005 3:33 PM" (contain part of the old
and part of the new value)?

Did I totally misunderstand your question? :)

[Fritz]

On Jan 15, 3:44 pm, "Rene" <[e-mail] e:

the value could contain part of the old and part of the new value

So are you saying that you are worried about having a stored value of say
"3/3/2003 3:33 PM" and then having the set method called to set a new value
of say "5/5/2005 5:55 AM" and during this process call the get method and
end up reading something like "5/5/2005 3:33 PM" (contain part of the old
and part of the new value)?

Did I totally misunderstand your question? :)

No, that is my concern. Although I'm not sure it would manifest itself
exactly like that (this would depend on the internal implementation
DateTime).

- Fritz

[DeveloperX]

On 15 Jan, 22:16, Fritz <fritzcw...@gma il.comwrote:

On Jan 15, 3:44 pm, "Rene" <[e-mail] e:

the value could contain part of the old and part of the new value

So are you saying that you are worried about having a stored value of say
"3/3/2003 3:33 PM" and then having the set method called to set a new value
of say "5/5/2005 5:55 AM" and during this process call the get method and
end up reading something like "5/5/2005 3:33 PM" (contain part of the old
and part of the new value)?

Did I totally misunderstand your question? :)

No, that is my concern. Although I'm not sure it would manifest itself
exactly like that (this would depend on the internal implementation
DateTime).

- Fritz

DateTime is a 64 bit structure. If you look at the MSDN entry there is
an explicit warning that it is not thread safe on certain
architectures as threads could switch before it is completely commited.

[Claes Bergefall]

"Fritz" <fr********@gma il.comwrote in message
news:dc******** *************** ***********@y5g 2000hsf.googleg roups.com...

On Jan 15, 3:44 pm, "Rene" <[e-mail] e:

the value could contain part of the old and part of the new value

So are you saying that you are worried about having a stored value of say
"3/3/2003 3:33 PM" and then having the set method called to set a new
value
of say "5/5/2005 5:55 AM" and during this process call the get method and
end up reading something like "5/5/2005 3:33 PM" (contain part of the old
and part of the new value)?

Did I totally misunderstand your question? :)

No, that is my concern. Although I'm not sure it would manifest itself
exactly like that (this would depend on the internal implementation
DateTime).

- Fritz

Yes, it looks like that could potentially happen (on 32-bit Windows). The
DateTime type stores its value internally as a UInt64. According to
http://msdn2.microsoft.com/en-us/library/ms684122.aspx, read and writes of
64 bit values are not guaranteed to be atomic on 32-bit Windows, so
potentially the writing thread might only get time to write half of the
bytes before it gets interupted by the reading thread.

I have no idea how common this problem is or if it even exists in practice.
The article only make a general statement regarding 32-bit Windows. The
behavoiur might very well be that it's an atomic operation on XP and Vista,
but not on 2000 for example (note: I'm only guessing here).

For the record, I've never seen it happen (fwiw :-)).

/claes

[Ajay Kalra]

Doing it on that granular a level actually increases your chances of

deadlock, assuming you are mixing it with other methods/properties that
lock on that granular a level.

Why is that though? I would have locking get/set of each property would be
better as long as the property is doing nothing but returning some state.

Also, in this case I would guess a reader/writer lock would work fine as
well.

---
Ajay

[Peter Duniho]

On Thu, 17 Jan 2008 19:31:19 -0800, Ajay Kalra <aj*******@yaho o.comwrote:

> Doing it on that granular a level actually increases your chances of
deadlock, assuming you are mixing it with other methods/properties that
lock on that granular a level.

Why is that though? I would have locking get/set of each property would
be better as long as the property is doing nothing but returning some
state.

Consider first that deadlocking code is buggy code. So the real question
is, why would locking at a finer level of granularity lead to more bugs?

The answer is simply that of opportunity. If you have only one lock,
there's no chance for deadlock at all. If you have two locks, there's
some chance for deadlock but it's not too hard to design around that
possibility. If you have fifty locks, then you've got some huge number of
permutations that could lead to deadlock. Make a single mistake and BOOM!

Pete

[Ajay Kalra]

"Peter Duniho" <Np*********@nn owslpianmk.comw rote in message
news:op******** *******@petes-computer.local. ..

On Thu, 17 Jan 2008 19:31:19 -0800, Ajay Kalra <aj*******@yaho o.com>
wrote:

>> Doing it on that granular a level actually increases your chances of
deadlock, assuming you are mixing it with other methods/properties that
lock on that granular a level.

Why is that though? I would have locking get/set of each property would
be better as long as the property is doing nothing but returning some
state.

Consider first that deadlocking code is buggy code. So the real question
is, why would locking at a finer level of granularity lead to more bugs?

The answer is simply that of opportunity. If you have only one lock,
there's no chance for deadlock at all. If you have two locks, there's
some chance for deadlock but it's not too hard to design around that
possibility. If you have fifty locks, then you've got some huge number of
permutations that could lead to deadlock. Make a single mistake and BOOM!

I didnt say that we have multiple lock objects. You can use the same object.
In this case, all getter can acquire a readonlylock. For setters, I would
use the same object on which you apply the lock. Why is that hmm... bad?

I am curious to know because we follow this pattern and have had no issues
at all. I would like to know the downside that we are missing.
---
Ajay