Locking Reference Objects

[Schroeder]

I have a DataSet that is cached deep down in a business layer object.
Higher up, there's a merge being performed on that object and it very
occassionaly throws a NullReferenceException deep down in the merge
code. I suspect that the DataSet is being edited during the merge by
another thread or its going out of scope (i.e. expiring).

The question is whether I can/should lock that reference object. Would
it help?

For example:

public SomeMethod() {
DataSet moreData = SomeObject.GetNonCachedData();
DataSet blah = SomeObject.GetCachedDataSet();
lock(blah) {
moreData.Merge(blah);
}
}

In this case 'blah' is a local object so it's not a threading issue per
se. I just think that another thread is affecting the cache and since
the DataSet is a reference object, it's causing this method to blow up.
What I'm really looking for is the best way to keep that reference
object from being edited during the merge. Is using that lock going to
help me?

 

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

Schroeder,

Is moreData a reference that is returned that is shared? If so, then
you should probably lock on this before you make changes to it.

Hope this helps.

 

[Jon Skeet [C# MVP]]

I have a DataSet that is cached deep down in a business layer object.
Higher up, there's a merge being performed on that object and it very
occassionaly throws a NullReferenceException deep down in the merge
code. I suspect that the DataSet is being edited during the merge by
another thread or its going out of scope (i.e. expiring).

The question is whether I can/should lock that reference object. Would
it help?

Very unlikely. One thread locking on something doesn't stop another
thread from doing something unless the second thread *also* tries to
lock on the same thing.

For example:

public SomeMethod() {
DataSet moreData = SomeObject.GetNonCachedData();
DataSet blah = SomeObject.GetCachedDataSet();
lock(blah) {
moreData.Merge(blah);
}
}

In this case 'blah' is a local object so it's not a threading issue per
se. I just think that another thread is affecting the cache and since
the DataSet is a reference object, it's causing this method to blow up.
What I'm really looking for is the best way to keep that reference
object from being edited during the merge. Is using that lock going to
help me?

Is this DataSet bound to any UI controls? If so, you shouldn't let any
thread other than the UI thread update it. Might that be part of the
problem?

 

[Schroeder]

moreData is not a reference to any shared data. It is only used by the
method in question.

 

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

Well, which ones are shared then?

 

[Jon Skeet [C# MVP]]

Is moreData a reference that is returned that is shared? If so, then
you should probably lock on this before you make changes to it.

That won't do any good unless anything else that uses it *also* locks
on it first.

 

[Schroeder]

I "refactored' the code to make it more clear.

public DataSet SomeMethod() {
DataSet nonSharedDataSet = SomeObject.GetNonCachedData(); // not
shared data...unique to this method
DataSet sharedDataSet = SomeObject.GetCachedDataSet(); // shared
data
lock(sharedDataSet) {
nonSharedDataSet.Merge(sharedDataSet);
}

return nonSharedDataSet
}

To answer Jon's question... yes, the results are being bound to a
control. The problem is that since it's working off of a shared cache
I can't really prevent other threads from modifying it. Or, at the
very least, I can't be sure that the cache isn't going to get blown
away by the cache engine due to age or memory usage.

 

[Jon Skeet [C# MVP]]

I "refactored' the code to make it more clear.

public DataSet SomeMethod() {
DataSet nonSharedDataSet = SomeObject.GetNonCachedData(); // not
shared data...unique to this method
DataSet sharedDataSet = SomeObject.GetCachedDataSet(); // shared
data
lock(sharedDataSet) {
nonSharedDataSet.Merge(sharedDataSet);
}

return nonSharedDataSet
}

To answer Jon's question... yes, the results are being bound to a
control. The problem is that since it's working off of a shared cache
I can't really prevent other threads from modifying it. Or, at the
very least, I can't be sure that the cache isn't going to get blown
away by the cache engine due to age or memory usage.

The cache being blown away isn't a problem, but you *must not* modify a
DataSet when it's bound to controls, unless you're "in" the UI thread.
The events fired would mean UI code getting executed in the wrong
thread.

This may or may not be what's causing your problem, but it's a
potentially serious design issue for you.