MultiThreading Dataset Strange Problem

[Matt Barley]

I have a multithreaded vb .net app that uses several datasets; all writes to
the datasets are synchronized using synclocks, no synchronization is used
for reads. No items or rows in the sets are being deleted, just updating
values. At random times it will break into the debugger with index outside
of the bounds of the array exceptions, when it does this the variable used
for the row index says it is zero which was normal and it even showed the
correct value for the item in the dataset. For example:

If CInt(CMPDAT.Tables(0).Rows(i).Item("ID")) = 0 Then

it showed that i was equal to zero and the value for "ID" was equal to one
which it should have been, but it still threw the exception?

Any help would be greatly appreciated.

 

[Brian Gideon]

I have a multithreaded vb .net app that uses several datasets; all writes to
the datasets are synchronized using synclocks, no synchronization is used
for reads. No items or rows in the sets are being deleted, just updating
values. At random times it will break into the debugger with index outside
of the bounds of the array exceptions, when it does this the variable used
for the row index says it is zero which was normal and it even showed the
correct value for the item in the dataset. For example:

If CInt(CMPDAT.Tables(0).Rows(i).Item("ID")) = 0 Then

it showed that i was equal to zero and the value for "ID" was equal to one
which it should have been, but it still threw the exception?

Any help would be greatly appreciated.

Hi,

Well, the documentation for a DataSet says, "This type is safe for
multithreaded read operations. You must synchronize any write
operations", but it's not clear exactly what that means. Does it mean
the data structure is thread-safe for one writer and multiple readers
like the Hashtable or is it thread-safe for multiple readers only when
there are no writers? I'm wondering if it's the later because if it
behaved like the Hashtable then I would expect the documentation to
read like it too.

When in doubt *always* synchronize multithreaded operations even if
they are just reads. Ya know...some data structures actually modify
themselves during reads (splay trees). And of course there's always
the problem of the reading thread seeing current state when
synchronization isn't used.

Brian

 

[Matt Barley]

Thanks Brian for the info. It seems that I only see the problem when i run
the program in the vs debugger; running the app on our target device for
several days now and it hasn't happened? Not sure what the debugger could
be doing to cause this. Now i am running the app on my development machine
outside the debugger and haven't seen any exceptions.

 

[Alvin Bruney [MVP]]

Thanks Brian for the info. It seems that I only see the problem when i

run the program in the vs debugger;

Well, that's a recipe for disaster because it will happen outside the
debugger. Eventually.

Multi-threaded issues are typically nasty to resolve - but you already knew
that.

My first step would be to use the test and load pattern on the dataset,
which you aren't doing. That won't fix the problem by the way.

if(ds != null && ds.Table != null && ds.Table.Count > 0 &&
ds.Table[0].Rows.Count > 0)
{
//access safely
}

If you get an exception on that part of the code, you can safely say that
the exception is not related to an index out of range, but more likely an
access violation/locking issue.

Try that first.