SyncLock and Array.SyncRoot and ReDim

Collapse
This topic is closed.
X
X
Collapse
 
  • Page of 1
  • Time
  • Show
Clear All
new posts
Previous template Next
  • eBob.com
    #1

    SyncLock and Array.SyncRoot and ReDim

    I was changing some code in a multi-threaded application today and noticed
    that it was not locking where it really needed to be locking. The Sub was
    already working with an array so I just stuck a SyncLock ArrayName.SyncR oot
    at the beginning of the Sub and an End SyncLock at the end. But this caused
    the application to produce no output (an Excel spreadsheet)! After some
    screwing around, sorry ... I mean experimenting, I noticed that the Sub
    contained a ReDim Preserve for the array, i.e. ArrayName. When I first
    noticed this I only wondered if that was thread safe, or if that was an
    additional reason why this routine needed locking. (ArrayName is accessed
    by all threads.) Then I thought, hmmm, if it is thread safe maybe it is
    already using SyncRoot and maybe that is my problem. Changed the SyncLock
    from SyncLock ArrayName.SyncR oot to SyncLock GetType(String) and all seems
    to be well. (I'll have to come up with something better than
    GetType(String) .)

    So I am wondering if it makes sense that you cannot use SyncLock
    Array.SyncRoot around code which is doing a ReDim Preserve Array, or maybe
    even just a ReDim Array? And, if so, does it make sense that you wouldn't
    get an exception?

    Bob


    Tags: None
    • Armin Zingler
      #2
      Re: SyncLock and Array.SyncRoot and ReDim

      "eBob.com" <eBob.com@total lybogus.comschr ieb
      I was changing some code in a multi-threaded application today and
      noticed that it was not locking where it really needed to be
      locking. The Sub was already working with an array so I just stuck
      a SyncLock ArrayName.SyncR oot at the beginning of the Sub and an End
      SyncLock at the end. But this caused the application to produce no
      output (an Excel spreadsheet)! After some screwing around, sorry
      ... I mean experimenting, I noticed that the Sub contained a ReDim
      Preserve for the array, i.e. ArrayName. When I first noticed this I
      only wondered if that was thread safe, or if that was an additional
      reason why this routine needed locking. (ArrayName is accessed by
      all threads.) Then I thought, hmmm, if it is thread safe maybe it
      is already using SyncRoot and maybe that is my problem. Changed the
      SyncLock from SyncLock ArrayName.SyncR oot to SyncLock
      GetType(String) and all seems to be well. (I'll have to come up
      with something better than
      GetType(String) .)
      >
      So I am wondering if it makes sense that you cannot use SyncLock
      Array.SyncRoot around code which is doing a ReDim Preserve Array, or
      maybe even just a ReDim Array? And, if so, does it make sense that
      you wouldn't get an exception?

      ReDim [Preserve] always creates a new array. The lock is still on the old
      array even if the new array has been assigned to the same variable that
      pointed to the old array before. The lock is on the object, not on the
      variable pointing to the object.


      Armin

        Comment

        • Cor Ligthert[MVP]
          #3
          Re: SyncLock and Array.SyncRoot and ReDim

          Bob,


          In addition to Armin, try forever to avoid the Redim, I have the idea that
          it is from the time of Basic 1.0 and absolute very inefficient to use.

          Cor

          "eBob.com" <eBob.com@total lybogus.comschr eef in bericht
          news:uxkoAaVLJH A.5596@TK2MSFTN GP03.phx.gbl...
          >I was changing some code in a multi-threaded application today and noticed
          >that it was not locking where it really needed to be locking. The Sub was
          >already working with an array so I just stuck a SyncLock ArrayName.SyncR oot
          >at the beginning of the Sub and an End SyncLock at the end. But this
          >caused the application to produce no output (an Excel spreadsheet)! After
          >some screwing around, sorry ... I mean experimenting, I noticed that the
          >Sub contained a ReDim Preserve for the array, i.e. ArrayName. When I first
          >noticed this I only wondered if that was thread safe, or if that was an
          >additional reason why this routine needed locking. (ArrayName is accessed
          >by all threads.) Then I thought, hmmm, if it is thread safe maybe it is
          >already using SyncRoot and maybe that is my problem. Changed the SyncLock
          >from SyncLock ArrayName.SyncR oot to SyncLock GetType(String) and all seems
          >to be well. (I'll have to come up with something better than
          >GetType(String ).)
          >
          So I am wondering if it makes sense that you cannot use SyncLock
          Array.SyncRoot around code which is doing a ReDim Preserve Array, or maybe
          even just a ReDim Array? And, if so, does it make sense that you wouldn't
          get an exception?
          >
          Bob
          >

            Comment

            Previous template Next
            Working...