|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
threads and hashtableHi,
I have one thread adding objects to a hashtable, and a bunch of other threads doing reads. MSDN says that multiple threads doing reads is safe. My question, is if my write thread is only adding new buckets to the hashtable, then there should not be a conflict w/ any other threads? Maybe the add() method somehow modifies the general state of the hashtable during the call, making it unsafe to read at that time. The bottom line is, does anyone know if I have to lock the add() operation? I do not want to do this if it is unnecessary. Thanks in advance! Yuri Hello, YuriL!
Y> Hi, Y> I have one thread adding objects to a hashtable, and a bunch of other Y> threads doing reads. MSDN says that multiple threads doing reads is Y> safe. My question, is if my write thread is only adding new buckets to Y> the hashtable, then there should not be a conflict w/ any other threads? Y> Maybe the add() method somehow modifies the general state of the Y> hashtable during the call, making it unsafe to read at that time. The Y> bottom line is, does anyone know if I have to lock the add() operation? Y> I do not want to do this if it is unnecessary. Add operation will influence count property. This can hurt your reading operation if it uses e.g. enumerator. So, to be thread save add must be also threadsafe... Take a look at Hashtable.Synchronized static method.
Show quote
"Vadym Stetsyak" <vady***@ukr.net> wrote in message This is OK for adding and accessing but it wont make enumeration safe.news:%23Z7zXjVOGHA.1312@TK2MSFTNGP09.phx.gbl... > Hello, YuriL! > > Y> Hi, > Y> I have one thread adding objects to a hashtable, and a bunch of other > Y> threads doing reads. MSDN says that multiple threads doing reads is > Y> safe. My question, is if my write thread is only adding new buckets to > Y> the hashtable, then there should not be a conflict w/ any other > threads? > Y> Maybe the add() method somehow modifies the general state of the > Y> hashtable during the call, making it unsafe to read at that time. The > Y> bottom line is, does anyone know if I have to lock the add() operation? > Y> I do not want to do this if it is unnecessary. > > Add operation will influence count property. This can hurt your reading > operation if it uses e.g. enumerator. > So, to be thread save add must be also threadsafe... > > Take a look at Hashtable.Synchronized static method. Hello, Nick!
Yes, I agree with you. Synchronized method won't influence enumeration. OTOH if we use have thread safe Hashtable ( obtained via Hashtable.Synchronized ), we can write following code Hastable hTbl; //our synchronized hashtable lock(hTbl) { foreach(object o in hTbl.Keys) {} } Vadym Stetsyak wrote:
> Hello, Nick! You have to lock on hTbl.SyncRoot.> > Yes, I agree with you. Synchronized method won't influence enumeration. > OTOH if we use have thread safe Hashtable ( obtained via Hashtable.Synchronized ), > we can write following code > > Hastable hTbl; //our synchronized hashtable > > lock(hTbl) hth, Max Thank you everyone for the feedback.
Yuri Show quote "Vadym Stetsyak" wrote: > Hello, Markus! > > Agreed > > -- > Regards, Vadym Stetsyak > www: http://vadmyst.blogspot "YuriL" <Yu***@discussions.microsoft.com> wrote in message Why not?news:92B7229B-1223-4FE7-93A3-2A587203079F@microsoft.com... > Hi, > I have one thread adding objects to a hashtable, and a bunch of other > threads doing reads. MSDN says that multiple threads doing reads is safe. > My question, is if my write thread is only adding new buckets to the > hashtable, then there should not be a conflict w/ any other threads? I would expect adding a bucket to redistribute all objects in the hashtable. Typically your access will be something like: Bucket b = buckets[o.GetHashCode()%NumBuckets]; > Maybe You are getting things backwards.> the add() method somehow modifies the general state of the hashtable > during > the call, making it unsafe to read at that time. The bottom line is, does > anyone know if I have to lock the add() operation? I do not want to do > this > if it is unnecessary. > Thanks in advance! > Yuri The rule for writing thread safe code is that unless the documentation explicitly says that it is safe it isn't. Even if it was somehow implemented in the way that you want in the current implementation it why should it stay the same next time? We've already seen someone post who thought that it was a bug because ah hashcode in 2.0 was different to one in 1.1  |
|||||||||||||||||||||||
Other interesting topics