Hashtable thread safety / documentation

[Guest]

I have a basic question regarding the Hashtable thread safety. According to
MSDN docs,
#1 Hashtable is thread safe for use by multiple reader threads, or a single
writing thread
#2 Synchronized supports multiple writing threads, provided that no threads
are reading the Hashtable. The synchronized wrapper does not provide
thread-safe access in the case of one or more readers and one or more writers

Section 2 basically says, multiple writers and no readers = ok, otherwise
you need to synchronize access yourself.

This seems to be out of sync with the behavior of the other collection
classes for which Synchronized method synchronizes all access when doing
individual operations like add, remove, read, update. Of course collection
enumeration is not thread safe. As an example look at SortedList.Synchronized.

The phrasing of the documentation seems strange to me, can somebody clarify
the behavior and confirm/deny if this is a documentation issue and Hashtable
behaves like all other collections?

 

[Marc Gravell]

Well, reading on a hashtable is inherently a multi-step operation;
first it needs to find the right bucket (by taking the hash/mod of the
key), then look at each item in that bucket to see if it Equals() the
key. As such, it is already comparable to enumeration.

Personally, I have found very little use in the Synchronised wrappers;
if I wany to work with the container, I lock the container (or it's
SyncRoot, or a separate sync object; it doesn't matter as long as
everybody agrees). This approach keeps things nice and simple to
debug. It is the rarety that I *only* want to add to a collection;
most of the time I want to check the existing contents (ContainsKey,
ContainsValue, perhaps) and maybe add something as a result. The
Synchronised wrapper cannot support this, as the read and write are
not atomic. A "lock, (read/write), unlock" approach guarantees that I
have the collection to myself for a few moments and can trust the
contents.

Marc

 

[Guest]

Thank you for your answer! I agree that Synchronized wrappers are not that
useful, however, in this particular case I need to know the exact behavior.

I don't think your argument that "reading on a hashtable is inherently a
multi-step operation;first it needs to find the right bucket (by taking the
hash/mod of the
key)" is valid because same applies to a SortedList, you have to traverse
the list in order to get to the element, and it's still safe to
read/write/update through the Synchronized wrapper, that's what the wrapper
is provided for. In addition, I shouldn't be concerned with the internal
implementation, the interface should describe the functionality and not
depend on the internal implementation.

 

[Marc Gravell]

OK, I'll concede the different behavior between this and SortedList -
but "internal implementation" is only applicable in the context of it
continuing to do what it says it will from documentation. Hashtable
makes no claim to offer safe reading via the synchronised wrapper;
that's all you
can assume. For people who find sync-wrappers useful, yes: it would be
nice if they all behaved the same. As is life. You could perhaos
create your own sync-wrapper?

Marc