SyncLock and Array.SyncRoot and ReDim

  • Thread starter Thread starter eBob.com
  • Start date Start date
E

eBob.com

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.SyncRoot
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.SyncRoot 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
 
eBob.com said:
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.SyncRoot 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.SyncRoot 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?
Click to expand...


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
 
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
 
Back
Top