2.0 Collections data

[Droopy]

Hi,

1) Is it worth to replace all HashTable and ArrayList (framework 1.1) usage
by Dictionary and List (framework 2.0) ?

I suppose the answer would be yes as the 2.0 collections are type safe and
should perform better.
But are there as reliable ?

2) In a multithreading environment, what is the best way to prevent
concurrent accesses ?

For now, I implemented a static function that returns a clone copy of the
data collection (protected by a lock based on the SyncRoot property of the
data collection). This copy is used by all running threads that needs read
or write access to collection elements. Is it necessary as the collection
object is not modified, only its elements are (add to and remove elements
from collection is also protected by a lock on SyncRoot property).


Thanks in advance,

Droopy.

 

[Cowboy \(Gregory A. Beamer\)]

1) Depends on whether or not you can type your collections. if so, moving to
the generci list and dictionary is a good idea. Example:

List<int> Dictionary<int, customer>

2) You should always have a monitor of some sort to guarantee consistent
state. This can be the Monitor class or a Mutex, both of which have plenty
of examples on the web.

In your case, if possible, you should only exclusively lock when you are
changing data, lest you lock up threads needlessly.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************************************************
Think outside of the box!
*************************************************

 

[Droopy]

1) Depends on whether or not you can type your collections. if so,
moving to the generci list and dictionary is a good idea. Example:

List<int> Dictionary<int, customer>

2) You should always have a monitor of some sort to guarantee
consistent state. This can be the Monitor class or a Mutex, both of
which have plenty of examples on the web.

In your case, if possible, you should only exclusively lock when you
are changing data, lest you lock up threads needlessly.

I think I was not precise enough for the second point.
When using the clone copy, I don't change the data collection so I should
not need locking but I read the whole collection with a foreach.
I think I read somewhere that there is a potential problem if the
collection is changed while a read with a foreach is performed.

Thanks already for your help.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Hi,

1) Is it worth to replace all HashTable and ArrayList (framework 1.1)
usage
by Dictionary and List (framework 2.0) ?

Are you having problem with them?
What is the cost of modifying the code? Remember that you will have to move
your code to 2.0 so others problems can arise at this point.

I suppose the answer would be yes as the 2.0 collections are type safe and
should perform better.
But are there as reliable ?

Yes, they are and they can indeed improve the performance, especially if you
have collections of valued types. Boxing/Unboxing can be an expensive
operation.

2) In a multithreading environment, what is the best way to prevent
concurrent accesses ?

Sync access to the collection.
Some collections already implement it, take a look at Queue

 

[Droopy]

Hi,



Are you having problem with them?
What is the cost of modifying the code? Remember that you will have
to move your code to 2.0 so others problems can arise at this point.


Yes, they are and they can indeed improve the performance, especially
if you have collections of valued types. Boxing/Unboxing can be an
expensive operation.


Sync access to the collection.
Some collections already implement it, take a look at Queue

It seems that the SyncRoot property that I used to Sync doesn't exist
anymore.
How do I lock on Dictionary object (readers enumerates on the Dictionary) ?

 

[Cowboy \(Gregory A. Beamer\)]

Yes, it is possible to get a "dirty read" if the collection is changed. You
CAN alter this by putting a Mutex on the collection when updating. This will
ensure the other threads cannot access the data during the update.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************************************************
Think outside of the box!
*************************************************