By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,666 Members | 1,784 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,666 IT Pros & Developers. It's quick & easy.

thread safety of hashtable

P: n/a
I have a hashtable which is accessed by two threads. One thread does
all writing and enumeration in the hashtable, and the other thread has
read-only access to the table directly through keys but never with
enumerators. Is there any reason to worry about synclocks?

thanks,
Keith
Jul 21 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Hi Keith,

Sure there is to worry.
This is what help says on this topic:
"To support one or more writers, all operations on the Hashtable must be
done through the wrapper returned by the Synchronized method.

Enumerating through a collection is intrinsically not a thread-safe
procedure. Even when a collection is synchronized, other threads could still
modify the collection, which causes the enumerator to throw an exception. To
guarantee thread safety during enumeration, you can either lock the
collection during the entire enumeration or catch the exceptions resulting
from changes made by other threads."

I hope it is clear enough (use Hashtable returned by Synchronized method +
lock it when doing enumeration)
--
Miha Markic - RightHand .NET consulting & development
miha at rthand com
www.rhand.com

"Keith Langer" <ta******@aol.com> wrote in message
news:15**************************@posting.google.c om...
I have a hashtable which is accessed by two threads. One thread does
all writing and enumeration in the hashtable, and the other thread has
read-only access to the table directly through keys but never with
enumerators. Is there any reason to worry about synclocks?

thanks,
Keith

Jul 21 '05 #2

P: n/a
Miha,

If you re-read my original post, you'll see that I only have one
writer thread, and it is also the only thread doing enumeration. The
other thread has read only access to the hashtable and does not use
enumeration. I don't believe that I'm meeting either criteria for
requiring synchronized access.

Keith

"Miha Markic" <miha at rthand com> wrote in message news:<#M*************@tk2msftngp13.phx.gbl>...
Hi Keith,

Sure there is to worry.
This is what help says on this topic:
"To support one or more writers, all operations on the Hashtable must be
done through the wrapper returned by the Synchronized method.

Enumerating through a collection is intrinsically not a thread-safe
procedure. Even when a collection is synchronized, other threads could still
modify the collection, which causes the enumerator to throw an exception. To
guarantee thread safety during enumeration, you can either lock the
collection during the entire enumeration or catch the exceptions resulting
from changes made by other threads."

I hope it is clear enough (use Hashtable returned by Synchronized method +
lock it when doing enumeration)
--
Miha Markic - RightHand .NET consulting & development
miha at rthand com
www.rhand.com

"Keith Langer" <ta******@aol.com> wrote in message
news:15**************************@posting.google.c om...
I have a hashtable which is accessed by two threads. One thread does
all writing and enumeration in the hashtable, and the other thread has
read-only access to the table directly through keys but never with
enumerators. Is there any reason to worry about synclocks?

thanks,
Keith

Jul 21 '05 #3

P: n/a
"Keith Langer" <ta******@aol.com> wrote in message
news:15*************************@posting.google.co m...
Miha,

If you re-read my original post, you'll see that I only have one
writer thread, and it is also the only thread doing enumeration. The
other thread has read only access to the hashtable and does not use
enumeration. I don't believe that I'm meeting either criteria for
requiring synchronized access.


Keith,

This would be true if writting into Hashtable is an atomic operation - which
it isn't.
What happens if writer thread is switched to reader thread in the middle of
writing operation to hashtable?

--
Miha Markic - RightHand .NET consulting & development
miha at rthand com
www.rhand.com
Jul 21 '05 #4

P: n/a
Miha,

If writer switches to reader, then nothing could be writing, so it
wouldn't matter. The real question is can I have one writer and one
reader (which does not enumerate). Could you explain what non-atomic
operations occur when writing to or reading from a hashtable?

Keith
"Miha Markic" <miha at rthand com> wrote in message news:<Ow**************@TK2MSFTNGP10.phx.gbl>...
"Keith Langer" <ta******@aol.com> wrote in message
news:15*************************@posting.google.co m...
Miha,

If you re-read my original post, you'll see that I only have one
writer thread, and it is also the only thread doing enumeration. The
other thread has read only access to the hashtable and does not use
enumeration. I don't believe that I'm meeting either criteria for
requiring synchronized access.


Keith,

This would be true if writting into Hashtable is an atomic operation - which
it isn't.
What happens if writer thread is switched to reader thread in the middle of
writing operation to hashtable?

Jul 21 '05 #5

P: n/a
Hi Keith,

"Keith Langer" <ta******@aol.com> wrote in message
news:15**************************@posting.google.c om...
Miha,

If writer switches to reader, then nothing could be writing, so it
wouldn't matter.
I am talking about two threads - one writer and one reader.

The real question is can I have one writer and one reader (which does not enumerate). Could you explain what non-atomic
operations occur when writing to or reading from a hashtable?


An atomic opertaion is the operation that can't be interupted.
As an example, assigning an integer is an atomic operation because it is
done in one procesor operation (at machine level).
So, it can't be interrupted by thread scheduler.
Assigning a string is not an atomic operation because it involves more than
one procesor's operation (allocating memory, copying chars, etc).
It *can* be interrupted by thread scheduler in the middle of assignment -
when part of the job is done and part not.
So, if you gonna read same string in the middle of assignment operation from
within another thread it will cause havoc because string will be in possibly
invalid state.
The same is true for hashtables - adding items is not an atomic operation.

HTH
--
Miha Markic - RightHand .NET consulting & development
miha at rthand com
www.rhand.com
Jul 21 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.