[ADVANCED-DOTNET] synchronization
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 W
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
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
sage-
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Brad Wilson
Sent: 09 February 2005 20:28
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] synchronization
It seems like using a ReaderWriterLock would be the best.
- Brad
On
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
don't;
}
}
Cheers,
Stoyan
http://spaces.msn.com/members/stoyan/
-Original Message-
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Alex
Smotritsky
Sent: 09.02.2005 18:11
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: [
EVELOP.COM
Subject: RE: [ADVANCED-DOTNET] synchronization
Date: Wed, 9 Feb 2005 11:10:35 -0500
>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
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?
This only applies when using COM+ synchronization
(System.EnterpriseServices.SynchronizationAttribute and ContextBoundObject).
If you exit the synch domain, then another thread can come and use the
method while you are waiting. Otherwise you continue to hold the lock used
for COM+ synchronization
The WaitHandle.WaitOne method takes two parameters, a timeout and a
Boolean value that the help described as "true to exit the
synchronization domain for the context before the wait (if in a
synchronized context), and reacquire it; otherwise, false."
Try as I might, I have been unable to figure ou
From: "Jeff Varszegi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 17, 2003 10:33 PM
Subject: [lists] Re: [ADVANCED-DOTNET] Synchronization question
> Yep, I definitely think you're right. I had the same idea a little while
ago, and I'm glad t
Yep, I definitely think you're right. I had the same idea a little while ago, and I'm
glad that
at least I'm not so stupid that it didn't hit me eventually. I now feel confident
sending my
friend an update, thanks to your letter (I don't have a Linux machine to test on right
now). I
didn't kn
the specifications for Monitor.Exit. The docs are pretty clear.
>
> -- arlie
>
>
> -Original Message-
> From: Moderated discussion of advanced .NET topics.
> [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Varszegi
> Sent: Friday, October 17, 2003 10:59 AM
> To: [EM
cussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff Varszegi
Sent: Friday, October 17, 2003 10:59 AM
To: [EMAIL PROTECTED]
Subject: [ADVANCED-DOTNET] Synchronization question
I've written some code that runs fine on Windows, but when someone tried
to run it under Mono
> The code in question is pretty detailed, but the synchronization scheme
boils down to this: I have
> two overlapping (avoiding the word "interlocked") synchronized regions,
where I start, the first,
> start the second, exit the first, then exit the second, like this:
>
> object monitor1 = new obj
I've written some code that runs fine on Windows, but when someone tried to run it
under Mono, it
threw this exception:
Unhandled Exception: System.Threading.SynchronizationLockException: Not locked by this
thread
The code in question is pretty detailed, but the synchronization scheme boils dow
Hi,
I am developing an application which will be served to more than hundred of
users in one second.
Of course, this is a roughly way of telling my case in an example like this.
Because the system will be served many users it has to be use any database
queries as seldom
as possible. So, I found a
27 matches
Mail list logo
