Using SyncLock to control access to a hastable

Hi, I have the following code

Dim htb as hashtable = htbTrades.Clone
htbTrades.Clear

Open in new window


In this example htbTrades is a hashtable that is declared as a global variable and can be added to by other threads.  I want to make sure that no items can be added to the htbTrades hashtable between the Clone and Clear operations.  Is SyncLock what I should be using.  Will the following achieve my objective.

Dim htb as hashtable
SyncLock htbTrades.SyncRoot
        htb = htbTrades.Clone
        htbTrades.Clear()
End SyncLock

Open in new window


Thanks
LVL 2
nicksbellAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

lojk.Net and Infrastructure ConsultantCommented:
http://msdn.microsoft.com/en-us/library/system.collections.hashtable.clone.aspx

Well - yes and no. It will only shallow copy the hashtable so a lot depends on what you are containing in the hashtable. Heres the best way i can explain that...

Imagine you have 10 cups on a table and each cup is connected to a Keyring via a peice of string. Cloning the hashtable merely adds another keyring and another 10 peices of string connected to the original cups.  If you want 10 more cups, then i think you may need to CopyTo instead.

If you are only storing value types (and/or strings) it should work fine but if you are using it to hold instances of complex types/classes you might need to check what you are trying to acheive is actually working correctly.
0
Mike TomlinsonMiddle School Assistant TeacherCommented:
You'd also have to place all ADDS to that HashTable within a similar SyncLock block.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
lojk.Net and Infrastructure ConsultantCommented:
I'm with idlemind - in fact i wouldn't even expose it is a global variable at all rather a private one with a readonly property and a few public methods to proxy access to it (AddToHash, CopyHash etc) with the synclocks in place in there.
0
Cloud Class® Course: SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

nicksbellAuthor Commented:
Thanks for your replies.

lokj, re my first comment, my issue is not with the Clone method.  I know that works for what I am trying to do as I already have that in production.  I simply want to make sure that no items can be added to the hashtable after Clone and before Clear, as then they would be lost altogether.  I am not worried about the underlying objects contained in the hashtable as they are static and are never updated, only new ones are added.

Idle_mind, ok, I didn't realise that but that makes sense.

lokj, just to clarify, are you suggesting I create a class that inherits the hashtable class and then expose a public AddToHash method (which would handle the synclock) and all other code would call AddToHash?  I guess that makes a lot of sense too as it stops the need for synclocks all over the place.
0
lojk.Net and Infrastructure ConsultantCommented:
not explicity saying an inherited class here more just a couple of helper methods in the global module to manage the utilisation of Idleminds point but i was going to suggest it and avoided it for simplicity reasons.

I think i would just create a Shared Class (module - not getting into that discussion now) with an private instance of the hashtable  and Get,Add,Delete,Clone,Clear methods that all implement the sync methods - it would always be fairly thread safe then.

MySafeHashTable.AddNewItem("key",Item);
Item = MySafeHashTable.GetItem("key");
MySafeHashTable.FlushAll();

The knock-on benefit to this approach would be by removing that global hash , you'd also weed out all those instances in your code where it's used allowing a nice simple hit list of places to change to the new methods.
0
nicksbellAuthor Commented:
Thanks, very useful
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
.NET Programming

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.