Re: Is this easy locking of a Hashtable's element too good to be true?
- From: "Mark S." <marks@xxxxxxxxx>
- Date: Fri, 30 Mar 2007 00:26:05 +0900
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.
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?
.
- Follow-Ups:
- Re: Is this easy locking of a Hashtable's element too good to be true?
- From: Nicholas Paldino [.NET/C# MVP]
- Re: Is this easy locking of a Hashtable's element too good to be true?
- References:
- Is this easy locking of a Hashtable's element too good to be true?
- From: Mark S.
- Re: Is this easy locking of a Hashtable's element too good to be true?
- From: Nicholas Paldino [.NET/C# MVP]
- Is this easy locking of a Hashtable's element too good to be true?
- Prev by Date: Re: Scrolling WebBroswer works, but not when it has proper DOCTYPE!
- Next by Date: 2 char's to 1 integer - and back.
- Previous by thread: Re: Is this easy locking of a Hashtable's element too good to be true?
- Next by thread: Re: Is this easy locking of a Hashtable's element too good to be true?
- Index(es):
Relevant Pages
|
