Plus, I'd reemphasize my original point (which I think you picked up),
that you should always do the simplest thing (Monitor), and profile
(preferably by instrumentation in a production-like environment) to
determine whether you actually have an issue with the code.
M
Matthew Adams
Director of R&
What the man said!
M
-Original Message-
Two issues:
(1) Monitor is simpler.
(2) It's significantly slower for a lot of cases.
--
Ian Griffiths - DevelopMentor
http://www.interact-sw.co.uk/iangblog/
> -Original Message-
> From: Brad Wilson
>
> What pain? It's already in the
This array based solution is something I'd consider if the relevant code
were looking like a hot spot. But I'd chose something simpler as my
first implementation, and only go for this extra complication if it
looks like it's needed.
But as for you final comment, yes - if the data is truly thread-
Two issues:
(1) Monitor is simpler. Any kind of locking is already pain, so
anything less simple than the simplest thing possible is pain. The extra
complexity, mild though it might be, means making ReaderWriterLock your
first choice is a premature optimization.
(2) It's significantly slower for
> I'm not sure about targeting both 1.0 and 1.1 from VS.Net 2003
We do this in my shop... we use VS2k3, but we do our official builds
w/ NAnt.exe -t:net-1.0, in at least two scenarios: (1) we build
component SDKs, and we want the widest possible customer base, and (2)
we make little powertoy app
Richter says that the .NET 1.1 MRSW lock does a ridiculous amount more work
than you'd think even when you're just doing the "I want to read, so block
writers (but not readers) until I'm done" or "I'm done reading" operation.
Unless a monitor lock would cause you to wait for another reader to f
In fairness, 'slower than Monitor' is a useless statement. Slower is
not necessarily a show stopper. You can't determine "too slow" --
which is radically different than "slower" -- without profiling your
specific application.
As it turns out, I wrote a very fast multi-reader, single-writer lock
in
> Helpfully, this is contradicted by the main documentation for the class
> itself:
>
> " To support one or more writers, all operations on the Hashtable must
> be done through the wrapper returned by the Synchronized method."
>
> This suggests that synchronization is always required for multithrea
And the implementation sucks -- it is (according to Jeffrey Richter) slower
than a Monitor in every case! Not very useful. (Hopefully it will be much
better in Whidbey.)
At 04:22 PM 2/9/2005, Brad Wilson wrote
>What pain? It's already in the FCL.
>
>- Brad
>
>On Wed, 9 Feb 2005 21:01:25 -,
What pain? It's already in the FCL.
- Brad
On Wed, 9 Feb 2005 21:01:25 -, Matthew W. Adams
<[EMAIL PROTECTED]> wrote:
> I would still try a regular Monitor-type lock and instrument for
> performance in an actual deployment scenario before going through the
> pain of implementing a reader/writ
I would still try a regular Monitor-type lock and instrument for
performance in an actual deployment scenario before going through the
pain of implementing a reader/writer lock.
M
Matthew Adams
Director of R&D
Digital Healthcare Ltd
http://spaces.msn.com/members/mwadams
-Original Message---
It seems like using a ReaderWriterLock would be the best.
- Brad
On Wed, 9 Feb 2005 20:07:37 -, Ian Griffiths <[EMAIL PROTECTED]> wrote:
> Helpfully, this is contradicted by the main documentation for the class
> itself:
>
> " To support one or more writers, all operations on the Hashtable mu
Patrick Steele wrote:
>
> See the Hashtable.Synchronized() method.
>
> "A Hashtable can safely support one writer and multiple readers
> concurrently. To support multiple writers, all operations must be
> done through this wrapper only."
Helpfully, this is contradicted by the main documentation
Thanks guys, Synchronized() it is!
-Original Message-
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Eric Means
Sent: Wednesday, February 09, 2005 12:13 PM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] synchronization
Two keys may map to the same bucket...
Use the Synchronized() method as Patrick noted; it's the easiest way
to be safe with multiple writers.
On Wed, 9 Feb 2005 11:10:35 -0500, Alex Smotritsky
<[EMAIL PROTECTED]> wrote:
> I'm hitting a global Hashtable with multiple threads each thread writing t
The first time any particular thread hits the Hashtable, the key it's using
won't be there and will need to be added. That means you'd need to synchronize.
It might make more sense to use an Array rather than a Hashtable; you'd need to
synchronize access only during the step that looks for an a
It depends, but I guess (watch for line breaks):
if (the elements are NOT precreated before the threads are launched) {
synchronize;
}
else // all elements are created, then the threads are launched {
if (you're changing the hashtable each time, e.g. hashtable[key] =
someValue)
{
See the Hashtable.Synchronized() method.
"A Hashtable can safely support one writer and multiple readers
concurrently. To support multiple writers, all operations must be
done through this wrapper only."
Original Message
From: [EMAIL PROTECTED]
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Su
I'm hitting a global Hashtable with multiple threads each thread writing to
it's own key-value pair in the Hashtable. Since no 2 threads will ever write
to the same key-value pair in the Hashtable, I'm not sure it's necessary to
synchronize access to it. Does anyone know?
19 matches
Mail list logo
