Locking Question around hashtable

[akantrowitz]

In csharp, what is the correct locking around reading and writing into
a hashtable. Note that the reader is not looping through the keys,
simply reading an item out with a specific key:

If i have the following hashtable h which has multiple readers and 1
writer (on different threads) is this the correct locking below:

[Reader]
lock (h.syncroot)
{
string r = h["Test"];
}
msgbox r;

[Writer]
string w = "Mike";
lock (h.syncroot)
{
h["Test"] = w;
}

 

[Jon Skeet [C# MVP]]

In csharp, what is the correct locking around reading and writing into
a hashtable. Note that the reader is not looping through the keys,
simply reading an item out with a specific key:

If i have the following hashtable h which has multiple readers and 1
writer (on different threads) is this the correct locking below:

<snip>

If you've just got a single writer and multiple readers, the
documentation states that you don't need any locking. However, I
suspect you *do* need locking if you want to make absolutely sure that
a reader will always see a writer's last write.

You could use a ReaderWriterLock for this, although others who have
used this (at least in 1.1 - not sure if it's fixed in 2.0 or not) have
said that ReaderWriterLock is so slow that it's usually much faster
just to take an exclusive lock every time (in which case your code is
fine).

Jon

 

[akantrowitz]

thanks for the response . .heres another followup question:

Lets say i have have a hashtable of hashtables (again on multiple
threads where there is one writer and multiple readers . .)

what would be the correct locking around the code below.

[Reader]
Hashtable n = h["Test'];
string Name = n["Joe"];

[Writer]
hash.Add("Joe", true);
h["Test"] = hash;

 

[Guest]

I recomend (till J Skeet did't come and criticise me ) to use ReaderWriter
lock if only one writer and several readers

Using the ReaderWriterLock class, any number of threads can safely read data
concurrently. Only when threads are updating is data locked. Reader threads
can acquire a lock only if there are no writers holding the lock. Writer
threads can acquire lock only if there are no readers or writers holding the
lock.

public class ReadWrite
{
private ReaderWriterLock rwl;
private HashTable h;

public ReadWrite()
{
rwl = new ReaderWriterLock();
}

public void ReadInts(ref int a, ref int b)
{
rwl.AcquireReaderLock(Timeout.Infinite);
try
{
string r = h["Test"];
}
finally
{
rwl.ReleaseReaderLock();
}
}

public void WriteInts(int a, int b)
{
rwl.AcquireWriterLock(Timeout.Infinite);

try
{
string w = "Mike";
h["Test"] = w;
}
finally
{
rwl.ReleaseWriterLock();
}
}
}

In csharp, what is the correct locking around reading and writing into
a hashtable. Note that the reader is not looping through the keys,
simply reading an item out with a specific key:

If i have the following hashtable h which has multiple readers and 1
writer (on different threads) is this the correct locking below:

--
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[Anders Borum]

You could use a ReaderWriterLock for this, although others who have

used this (at least in 1.1 - not sure if it's fixed in 2.0 or not) have
said that ReaderWriterLock is so slow that it's usually much faster
just to take an exclusive lock every time (in which case your code is
fine).

I would like to back this statement with personal experience from a
framework that had to support locking of shared resources. We first went
with the ReaderWriterLock but resorted to the lock() statement, because it
was a lot faster (and I really mean a lot).

 

[Nick Hounsome]

<snip>

If you've just got a single writer and multiple readers, the
documentation states that you don't need any locking.

Which documentation?

QUOTE
Thread Safety
To support one or more writers, all operations on the Hashtable must be done
through the wrapper returned by the Synchronized method.

UNQUOTE

 

[Jon Skeet [C# MVP]]

Which documentation?

QUOTE
Thread Safety
To support one or more writers, all operations on the Hashtable must be done
through the wrapper returned by the Synchronized method.
UNQUOTE

Good question. I *know* that the documentation did at one stage say
that it was safe for a single writer and multiple readers - but I can't
find it now

(I seem to remember that at the time that it said it was safe in that
way, the Thread Safety section itself was the standard "instance
members aren't threadsafe" docs, so it was already self-contradictory.)

Jon

 

[Nick Hounsome]

Good question. I *know* that the documentation did at one stage say
that it was safe for a single writer and multiple readers - but I can't
find it now

(I seem to remember that at the time that it said it was safe in that
way, the Thread Safety section itself was the standard "instance
members aren't threadsafe" docs, so it was already self-contradictory.)

You should be OK(ish) provided that you don't add or remove items.
Reading or changing (h[a]=b) should probably be alright but things would go
horribly wrong if a bucket was added or an element chained whilst a read was
in progress without some locking

 

[Guest]

Good question. I *know* that the documentation did at one stage say
that it was safe for a single writer and multiple readers - but I can't
find it now

Maybe I've read abt ReaderWriterLock? Coz it's stated in MSDN that this type
is safe for multithreaded operations

 

[Nick Hounsome]

Maybe I've read abt ReaderWriterLock? Coz it's stated in MSDN that this
type
is safe for multithreaded operations

It is but we were talking about a bare Hashtable

Also what Jon said about RW locks is generally true - if you are just doing
simple access then locking the whole thing is going to be quicker and
easier - RW locks are only worthwhile if the readers are spending a lot of
time rummaging around in a data structure - tree walking would be the most
common use.

 

[Jon Skeet [C# MVP]]

Good question. I *know* that the documentation did at one stage say
that it was safe for a single writer and multiple readers - but I can't
find it now

(I seem to remember that at the time that it said it was safe in that
way, the Thread Safety section itself was the standard "instance
members aren't threadsafe" docs, so it was already self-contradictory.)

You should be OK(ish) provided that you don't add or remove items.
Reading or changing (h[a]=b) should probably be alright but things would go
horribly wrong if a bucket was added or an element chained whilst a read was
in progress without some locking

I looked into it a little while ago, and I *think* I came to the
conclusion that the way it was written, even additions and removals
would be okay so long as you genuinely only had a single writer - you
just wouldn't see modifications until the reading thread picked up the
potentially new bucket structure.

Then again, I'm not an expert in hashtable implementations by any
stretch of the imagination (and in my experience people are willing to
stretch their imaginations a long way when it comes to calling someone
an expert). I personally wouldn't normally trust it, but then I'm
pretty paranoid when it comes to threading...

Jon

 

[Nicholas Paldino [.NET/C# MVP]]

I'll back that statement about the HORRENDOUS performance of the
ReaderWriterLock class.

Also, this was NOT fixed in 2.0. Maybe 3.0?

 

[Jon Skeet [C# MVP]]

I'll back that statement about the HORRENDOUS performance of the
ReaderWriterLock class.

Indeed, it was mostly you I was thinking of

Also, this was NOT fixed in 2.0. Maybe 3.0?

That's useful (I originally wrote 'good', but then thought better of
it) to know. Someone pester me if I haven't written up a few tests etc
about it in my threading tutorial some time in the next week...

Jon

 

[Brian Gideon]

I would like to back this statement with personal experience from a
framework that had to support locking of shared resources. We first went
with the ReaderWriterLock but resorted to the lock() statement, because it
was a lot faster (and I really mean a lot).

I typically avoid the ReaderWriterLock altogether. Threading is
already hard enough so I try to keep things simple at the expense of
performance. There is a better chance that I'll make a mistake if I
try to get too fancy with it. And, as you pointed out, the
ReaderWriterLock only performs better in a limited number of scenarios
anyway.

Brian

 

[Jon Skeet [C# MVP]]

I typically avoid the ReaderWriterLock altogether. Threading is
already hard enough so I try to keep things simple at the expense of
performance. There is a better chance that I'll make a mistake if I
try to get too fancy with it.

That is absolutely the best policy, IMO. When in doubt, keep it simple.
Performance problems are very rarely where people expect them to be
anyway

Jon

 

[Jon Skeet [C# MVP]]

thanks for the response . .heres another followup question:

Lets say i have have a hashtable of hashtables (again on multiple
threads where there is one writer and multiple readers . .)

what would be the correct locking around the code below.

[Reader]
Hashtable n = h["Test'];
string Name = n["Joe"];

[Writer]
hash.Add("Joe", true);
h["Test"] = hash;

Well, what level of atomicity do you need? Is it important to you that
nothing "interrupts" the two operations in each case? If not, just lock
each statement:

Hashtable n;
lock (h.SyncRoot)
{
n = (Hashtable) h["Test"];
}
string name;
lock (n.SyncRoot)
{
name = (string) n["Joe"];
}

(and likewise for the write).

If you *do* need to make the pair of reads/writes truly atomic, you
need to nest the locks - but make sure you always acquire them and
release them in the same order wherever you use them, otherwise you'll
get a deadlock!

It may well be simpler in that situation to use a single lock which is
always acquired when using either hashtable...

 

[Guest]

Some interesting info for people using hashtables:
1. When threading use the synchronized hastable wrapper if you are not
worried about not seeing writes immediately when done from another thread.
2. The synchronized hashtable only locks on deletions internally as it
copies buckets normal to avoid locking
3. Given the above implementation it is slow, but provides good parallelism
and reduced contention
4. Given #1 is ok for you, you only need to lock if you need to enumerate
all of the elements in the hashtable since the enmerator is not thread safe.
5. For even higher performance given a well known dataset and using strings
as keys you might try a different hash algorithm, the MS one is nicely
distributed producing few collisions but is slow compared to other algorithms
that would produce more collisions for large data sets, but if your data set
is well known or small and diverse some more simplistic algorithms may work
for you.


This is based on a rough idea of .NET 1.1, examining through reflector and
such.
Obviously these internals may change in future versions.