Is this easy locking of a Hashtable's element too good to be true?

  • Thread starter Thread starter Mark S.
  • Start date Start date
M

Mark S.

Much to my surprised the code below compiled and ran. I just don't know
enough about threading to know for sure if this is too good to be true.

I'm attempting to isolate the Hashtable lock to "row level", the whys aren't
important at this time. Does this code actually do what I want?

using System;
using System.Collections;
using System.Collections.Generic;
using System.Text;

namespace ConsoleForTesting
{
class testHashTableElementLock
{
public static Hashtable ht = Hashtable.Synchronized(new
Hashtable());

static void Main(string[] args)
{
ht["row1"] = "hello world";
Console.WriteLine(ht["row1"]);

lock (ht["row1"])
{
ht["row1"] = "hi there";
}

Console.WriteLine(ht["row1"]);

Console.ReadLine();
}
}
}
 
Mark,

You should clarify what you mean by "row level". The statement itself
says that you want to lock operations on a specific row, however your code
says something different. It seems like what you want to do is isolate
operations on a thread that deal with an element in the hash table.

Your code is only off by a little bit. Instead of locking on
ht["row1"], you should lock on ht. The reason for this is that ht["row1"]
will return an object, but it doesn't synchronize access to the hashtable
itself. Since you are trying to change what a key is associated with, you
have to work on this level.

Now, because you have a synchronized version of the hash table, you
don't have to use the lock statement at all. It's built in for you.

If you didn't have the synchronized hash table, then you would have to
do:

static void Main(string[] args)
{
lock (ht)
{
ht["row1"] = "hello world";
}

lock (ht)
{
Console.WriteLine(ht["row1"]);
}

lock (ht)
{
ht["row1"] = "hi there";
}

lock (ht)
{
Console.WriteLine(ht["row1"]);
}

Console.ReadLine();
}

Now, all of those lock blocks could be combined in various ways. That
depends on how you want your operations to be broken up, and if you want
other threads to have access to any blocks of code locked with ht in between
operations.

Hope this helps.
 
Niccholas,
says something different. It seems like what you want to do is isolate
operations on a thread that deal with an element in the hash table.
Correct.

Your code is only off by a little bit. Instead of locking on
ht["row1"], you should lock on ht. The reason for this is that ht["row1"]
will return an object, but it doesn't synchronize access to the hashtable
itself. Since you are trying to change what a key is associated with, you
have to work on this level.
Click to expand...

There's the rub. I need to lock the "row" because the app is under heavy
load by many users and the business logic dictates that each requests knows
what the other did, make a desicion and then save the result back in to the
row.

By locking the entire Hashtable it blocks all the other threads from doing
their business on other keys. This creates a bottoleneck in my app.

I'd like to enable multple threads to work on other "rows" simoutanously.
Making threads wanting the same "row" wait with a lock is not only okay, but
required.

Any ideas?
 
Mark,

You don't understand, you don't have a choice in the matter. You are
trying to synchronize access to the hashtable. When you are retrieving an
item from the hashtable, or changing the value that a key points to, you
need to make sure that only one thread at a time is accessing the hashtable.

Then, when you get an object from the hashtable, if you need to
synchronize access to that object, then you can lock on that. However, when
you are accessing the internal data to the hashtable (by reading an object
with a key, or setting a new key), synchronization to the hashtable is a
must.

If you are going to use the synchronized version of the hashtable, then
you don't have to use the lock statement (at least when it comes to the
hashtable itself, for things retrieved from the hashtable, you do).
Generally, I would use the lock statement, since you will more than likely
need to lock off blocks of code, and not just single operations.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Mark S. said:
Niccholas,
says something different. It seems like what you want to do is isolate
operations on a thread that deal with an element in the hash table.
Correct.

Your code is only off by a little bit. Instead of locking on
ht["row1"], you should lock on ht. The reason for this is that
ht["row1"] will return an object, but it doesn't synchronize access to
the hashtable itself. Since you are trying to change what a key is
associated with, you have to work on this level.
Click to expand...

There's the rub. I need to lock the "row" because the app is under heavy
load by many users and the business logic dictates that each requests
knows what the other did, make a desicion and then save the result back in
to the row.

By locking the entire Hashtable it blocks all the other threads from doing
their business on other keys. This creates a bottoleneck in my app.

I'd like to enable multple threads to work on other "rows" simoutanously.
Making threads wanting the same "row" wait with a lock is not only okay,
but required.

Any ideas?
Click to expand...
 
Nicholas,

I assume your decision to use lock statement is based upon this description
from msdn:
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.

Enumerating through a collection is intrinsically not a thread safe
procedure. Even when a collection is synchronized, other threads can 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.

Reference:
http://msdn2.microsoft.com/en-us/library/system.collections.hashtable.synchronized.aspx


I guess it would be silly to use Synchronized to write and Lock to read. I
would say that you are better off not using syncrhozied at all.

Dave
 
Back
Top