locked
Modifying DataView thread safety RRS feed

  • Question

  • I am parallelizing some of my code, and in this section, I have DataViews accessing a common DataTable. There are places where I modify the DataViews, but in necessarily discrete records among the threads. Do I still need to institute Semaphores for these modifications (not row addition/deletions, but only mods), if I know that specific records won't be touched simultaneously?
    Tuesday, January 22, 2013 2:41 PM

All replies

  • A DataView does not access a DataTable. It can be inside a DataTable (the property DefaultView), but it is in fact only a kind of filter setting to be used mostly at presentation time (also to get a new partial table with the CopyTo method).

    How far those filters can bite each other is up to you. 


    Success
    Cor

    Wednesday, January 23, 2013 10:17 AM
  • A DataView does not access a DataTable.

    Actually; yes, it does. A DataView is its own class. It is not "inside" a DataTable. The DataView references the same memory location as the DataTable it is filtering. i.e. A change to the contents of the DataView immediately changes the DataTable it is filtering, because they reference the same locations in memory. I'm not sure why you are saying "a DataView does not access a DataTable," and in any case, it doesn't address my original question.
    Wednesday, January 23, 2013 2:19 PM
  • A DataView does not access a DataTable.

    Actually; yes, it does. A DataView is its own class. It is not "inside" a DataTable. The DataView references the same memory location as the DataTable it is filtering. i.e. A change to the contents of the DataView immediately changes the DataTable it is filtering, because they reference the same locations in memory. I'm not sure why you are saying "a DataView does not access a DataTable," and in any case, it doesn't address my original question.

    You know it, sorry, tried to give you my best answer, I always thought it was as I wrote.

    But in my idea is what you write wrong or let say complete nonsense, before somebody gets the idea that with the sentence above I tell the opposite.

    As it is about your original question header and not the text in it. 

    An instanced DataView is an object of the Type DataView, I'm not aware of any description of "own" classes in .Net.

    A DataView does not change a DataTable immedialely. However, like I wrote already it can influence the behavior of the UI if that should not be done then maybe it is preferable to lock it, using the lock mechanism as soon as you intent to change properties. But even then I think it can give strange behavior for those looking at a control at that time which is bound to that dataview. 

    But that synchronizing lock is not an AdoNet question, more a question for the general forum of the language you are using.

    In VB the name is Synclock in VC# it is lock.

     


    Success
    Cor



    • Edited by Cor Ligthert Wednesday, January 23, 2013 6:00 PM
    Wednesday, January 23, 2013 5:57 PM
  • A DataView does not change a DataTable immedialely.

    Sure it does. I don't know why you say that, Cor.

    @cgtyoder -- I think that as long as you're not adding/removing rows, and you're sure that you're always updating rows that other threads don't use/need/care about, then I don't think you'd need to worry about locking. I've never done that, so take what I say "with a grain of salt" ... but it should be ok.


    ~~Bonnie Berent DeWitt [C# MVP]

    geek-goddess-bonnie.blogspot.com

    Saturday, January 26, 2013 5:51 PM
  • This was on my To Do list to respond to today - I did proceed under that assumption, BonnieB, but as I found out, that doesn't work. If I try to update a row in one thread and create a new DataView in another thread, the DataView creation may fail. So that takes away a lot of parallelism that I was hoping for. Thanks anyways for your response!
    Saturday, January 26, 2013 6:29 PM
  • Interesting ... how does it fail (does it throw an exception)? I'm assuming that you create the DataView by the following code?

    DataView dv = new DataView(MyTable);


    ~~Bonnie Berent DeWitt [C# MVP]

    geek-goddess-bonnie.blogspot.com

    Saturday, January 26, 2013 8:57 PM
  • Yes - throws an Exception. Sorry, I did not write down the details. I was actually using the new DataView(table, filter, sort, rowstate) version of the ctor.
    Saturday, January 26, 2013 9:09 PM
  • What's the exception? (I'm actually only curious ... I doubt if I'd have any idea how to help).

    Have you tried the simpler ctor, just the table?


    ~~Bonnie Berent DeWitt [C# MVP]

    geek-goddess-bonnie.blogspot.com

    Saturday, January 26, 2013 9:23 PM
  • A DataView does not change a DataTable immedialely.

    Sure it does. I don't know why you say that, Cor.

    @cgtyoder -- I think that as long as you're not adding/removing rows, and you're sure that you're always updating rows that other threads don't use/need/care about, then I don't think you'd need to worry about locking. I've never done that, so take what I say "with a grain of salt" ... but it should be ok.


    ~~Bonnie Berent DeWitt [C# MVP]

    geek-goddess-bonnie.blogspot.com

    Bonnie,

    Have you any link to an MSDN library part where that is described.

    I'm not aware how an object in .Net can be affected by only setting or changing its properties another object. The only thing you can do with the DataView Object is to create a new DataTable with it. But afaik does it not affect in any way a datatable.

    Therefore you make me very curious because it would bring a new view on .Net programming.


    Success
    Cor

    Sunday, January 27, 2013 10:40 AM
  • Cor, if you create a DataView, based on a particular DataTable, and then modify a value in a column of a row in that DataView, that same column in the corresponding row in the DataTable is also modified. That's because when you are working with a DataView, it's simply a "filtered view" of the DataTable and you are, in actuality, working on the DataTable itself. 

    I can't believe that you didn't know that ... or are we misunderstanding each other's point?


    ~~Bonnie Berent DeWitt [C# MVP]

    geek-goddess-bonnie.blogspot.com

    Sunday, January 27, 2013 4:15 PM
  • Bonnie,

    Now I see the confusion. It is used by you that the DataView has members which can Access the dataTable and do changes to it.

    You are right, wrongly interpreted that part of the text.

    Sorry

    Cor



    Sunday, January 27, 2013 7:46 PM
  • Bonnie,

    Maybe you saw I did many changes to my last reply to you, therefore I write this separately. 

    I used my text in this thread in the way that a change to a DataView does not change the DataTable itself and therefore it has no relation to thread safety. However, if a DataView method is used in an extra thread, then the underlying DataTable has of course to by Synclocked (Synclock in VB and lock in C#). I see still no reasons to sync lock a dataview beside what I wrote in this thread.



    Success
    Cor

    Sunday, January 27, 2013 8:00 PM
  • cgtyoder -- I'm sorry, but I'm kind of late in remembering that DataSets are absolutely NOT thread-safe! That just suddenly popped into my head this morning, out of the blue. I knew that, but forgot about it (one of the downsides of getting old)!! So all the stuff that Cor said about needing to use a lock on the DataTable is absolutely right!!

    Cor -- Yes, apparently we misunderstood each other. I think I *still* misunderstand you, but that's ok ... maybe it's just me! LOL


    ~~Bonnie Berent DeWitt [C# MVP]

    geek-goddess-bonnie.blogspot.com

    Sunday, January 27, 2013 9:59 PM
  • "The only thing you can do with the DataView Object is to create a new DataTable with it. But afaik does it not affect in any way a datatable"

    It is nonsense! Read before you give an advice:

    DataView Class

    "Represents a databindable, customized view of a DataTable for sorting, filtering, searching, editing, and navigation. The DataView does not store data, but instead represents a connected view of its corresponding DataTable. Changes to the DataView’s data will affect the DataTable. Changes to the DataTable’s data will affect all DataViews associated with it."

    https://msdn.microsoft.com/en-us/library/system.data.dataview%28v=vs.110%29.aspx

    Tuesday, November 22, 2016 2:40 PM
  • Bonnie,

    Maybe you saw I did many changes to my last reply to you, therefore I write this separately. 

    I used my text in this thread in the way that a change to a DataView does not change the DataTable itself and therefore it has no relation to thread safety. However, if a DataView method is used in an extra thread, then the underlying DataTable has of course to by Synclocked (Synclock in VB and lock in C#). I see still no reasons to sync lock a dataview beside what I wrote in this thread.


    Why a DataView method??  Change of data can be made by user via UI bound to DataView....
    Changes of data (the data in DataViewRow object, which is connected to DataRow of DataTable) are projected to DataTable. Changes are commited to DB after DataTable.AcceptChanges() or DataSet.AcceptChanges() (or rolled back by RejectChanges).

    Tuesday, November 22, 2016 2:59 PM
  • Yes, you are absolutely right.
    Tuesday, November 22, 2016 3:07 PM
  • Yes, you are absolutely right.

    Need a little context there, Pavel ... without a quote no one has any idea which reply you're referring to.

    ~~Bonnie DeWitt [C# MVP]

    http://geek-goddess-bonnie.blogspot.com

    • Edited by BonnieBMVP Tuesday, November 22, 2016 3:26 PM
    Tuesday, November 22, 2016 3:23 PM